2010-12-30 6 views
8

Ich habe gerade Resharper verwendet und es hat mir das Gefühl gegeben, als ob ich überhaupt nicht in C# programmieren kann; es gab mir viele Vorschläge; Einige von ihnen sind:C-Code-Bereinigung: Nachschärfer

var o = new SomeObject() 

2) this.Loaded += new RoutedEventHandler(MainPage_Loaded);

zu

this.Loaded += MainPage_Loaded; 

3) konvertieren meine Variablen und setzen:

1) SomeObject o = new SomeObject();

ReSharper konvertieren _ vor allen Instanzvariablen.

4) Entfernen des Namens des Klassenelternteils. Ich habe das auf Silverlight getestet.

public partial class MainPage : UserControl 

zu

public partial class MainPage 

5) Instanzvariable

this.variable = somevalue 

zu

variable = somevalue 

Sind alle diese wirklich notwendig ersetzen? Wird es wirklich die Effizienz meines Programms beeinflussen? Ich meine, was gut es tun wird, indem ich meine Klassennamen durch var Schlüsselwort ersetze. Immerhin wird zur Kompilierzeit auch var durch den Klassennamen ersetzt. Tut es, weil es hat programmiert wurde, um zu tun, oder diese Dinge wirklich beeinflussen auf irgendeine oder andere Weise?

+0

Ich zweifle wirklich an Punkt 4. Es bricht die Vererbung. –

+3

@Madhur: Es würde nur tun, wenn das andere Stück der partiellen Klasse deklariert wurde, von UserControl zu erben. –

+0

@Madhur: +1 auf Joes Kommentar. Vergiss nicht, dass diese Klasse "Teilweise" ist. –

Antwort

8

Dieses Verhalten ist alles konfigurierbar in ReSharper Einstellungen. Es gibt eine Mischung aus Codebereinigungsregeln (z. B. ob Benutzungen durch var ersetzt werden sollen - tue ich nicht!), Codestilregeln (z. B. Variablennamen) und Formatierungsregeln (z. B. wie geschweifte Klammern platziert werden).

Ich schrieb einen Artikel, der einen Überblick über diese Einstellungen und wie sie gibt Standards Codierung verwendet werden kann, formen und dann automatisch über Code Bereinigung angewandt werden:

http://gojisoft.com/blog/2010/05/10/coding-standards-using-resharper/

Am Ende des Tages eines Viele von ihnen befassen sich mit dem Codierungsstil und entfernen redundanten Code, sie haben keinen Einfluss auf den kompilierten Code. Sie können viele von ihnen so konfigurieren, dass sie Ihnen oder dem Codierungsstil Ihres Teams entsprechen.

2

Alle diese Änderungen sollten keinerlei Auswirkungen auf den kompilierten CIL-Code haben - sie sind nur die Meinung von ReSharper zur Lesbarkeit des C# -Codes selbst.

Sie können alle Einstellungen an Ihre Bedürfnisse anpassen. Meistens ist es eine Frage der persönlichen Präferenz.

3

Sie sind nicht notwendig.

Sie folgen einem Kodierungsstandard, der durch Nachschärfung festgelegt wird. Das Schöne ist, dass Sie den Codierungsstandard auf Ihre eigene Art und Weise konfigurieren können.

Die schöne Sache über Resharper ist, dass Sie am Ende verschiedene Arten lernen, etwas zu tun, was Sie immer auf eine bestimmte Weise getan haben.

5

Sind alle diese wirklich notwendig?

Keine sind notwendig.

Wird es wirklich die Effizienz meines Programms beeinflussen?

Es wirkt sich nicht auf den kompilierten Code in einer Weise aus, die Leistung oder Semantik überhaupt ändert.

Ich meine, was gut zu tun ist, indem ich meine Klassennamen durch var Schlüsselwort ersetzen. Nach alle Var wird auch zum Kompilierungszeitpunkt mit Klassennamen ersetzt.

Besser lesbarer Code.

Tut es, weil es programmiert wurde, um zu tun oder haben diese Dinge wirklich auf irgendeine oder andere Weise Einfluss?

Ja. Diese sind konfigurierbar, wenn Sie sie nicht mögen.

1) Ist in Ordnung.

SomeObject o = new SomeObject(); 

Die erste SomeObject ist überflüssig und nutzlos und mit var es ist nicht weniger lesbar und wohl besser lesbar. Zusätzlich für komplexe Definitionen wie

ist es viel lesbarer als die Alternative. Dies kann jedoch übertrieben sein. Zum Beispiel

string s = "s"; 

wird bevorzugt über

var s = "s"; 

als

ist
var i = 5; 

über

int i = 5; 

Beachten Sie, dass

var i = 2147483648; 

ist wirklich schlecht, weil es nicht sofort klar ist, was der Typ i ist. Für nicht komplexe Definitionen bevorzuge ich explizite Typisierung gegenüber impliziter Typisierung. Zusätzlich manchmal möchte man sagen

IFoo foo = new Foo(); 

ausdrücklich foo eine IFoo während eingeben var würde es als Foo geben.

2) Weniger Code ist im Allgemeinen besser Code.

3) Ich hasse diesen Vorschlag. Ich hasse die führende Unterstreichung. Ich benutze die übliche Benennungskonvention für meine Mitgliedsvariablen und stelle sie zur Klarheit mit this voran. Ich würde das hier abstellen.

public SomeObject(string name) { 
    this.name = name; 
} 

ist besser lesbar als

public SomeObject(string name) { 
    _name = name; 
} 

meiner Meinung nach.

4) Warte, warum macht es das? Ich bin etwas verwirrt von diesem. Weil es partiell ist und ein anderer Teil der Klassendefinition die Vererbung hat? Ich kann mir nicht vorstellen, dass dies in einem Fall geschieht, in dem sich die Semantik ändert. Ich würde das hier abstellen.

5) Ich habe nicht diesen mag (siehe 3.)

+0

Zu # 4: Wie in den Kommentaren zum OP darauf hingewiesen, ReSharper schlägt nur vor, wenn die Basisklasse von einem anderen Teil der partiellen Klasse deklariert wird. In diesem Fall kann ich ziemlich sicher sein, dass wir den Code-Behind eines WPF UserControls sehen, dessen XAML-Frontend die Basisklasse deklariert. –

+0

@djacobson: Ah, danke. Persönlich denke ich, es ist klarer mit der redundanten Aussage der Basisklasse. – jason

+0

Zu # 4, ich entferne immer die redundante Basisklasse. Es macht es einfacher, wenn ich später mein Fenster zu einem Benutzersteuerelement oder mein Benutzersteuerelement zu einer Seite ändern möchte - ich muss nur das XAML ändern und alles funktioniert einfach. Wenn Sie das redundante ": UserControl" beibehalten, müssten Sie beide Stellen (XAML und Codebehind) ändern. TROCKEN. –

Verwandte Themen