2009-08-19 13 views
6

Ho appena installato Reshaper 4.5 ed è venuto su con i seguenti suggerimenti:Il ricondizionatore è corretto?

return this.GetRuleViolations().Count() == 0; -- REMOVE this. 

new string[] { this.ID.ToString(), this.Registration } -- REMOVE string, MAKE ANONYMOUS TYPE 

int i = Method.GetNumber(); -- REPLACE int WITH var 

devo fare questi?

Penso che in alcuni casi renderà il codice meno leggibile ma migliorerà le prestazioni? quali sono i vantaggi di apportare queste modifiche?

Grazie

+1

C'è solo una canzone Rigobert. Assicurati di controllare le varie occorrenze dup delle sottolicità di questo forum. –

+1

Prova a installare StyleCop e StyleCop-for-ReSharper che ti forniranno le linee guida sullo stile di codifica consigliate da Microsoft. Dovrai però modificare le regole di R # per farle combaciare. Per quanto riguarda l'uso di var, lo usiamo sempre internamente in quanto aiuta a leggere a nostro avviso - i tipi sono per il compilatore, non per gli umani. –

+1

Hm. Ho sempre usato il tipo - credo che dovresti essere consapevole di quello che stai tornando dalle tue espressioni lambda, e aiuta un po 'se lo stai specificando a priori. – Yablargo

risposta

12

1) Il puntatore esplicito this è necessaria solo quando il riferimento sarebbe altrimenti sii ambiguo. Poiché il tipo GetRuleViolations è definito, molto probabilmente non è necessario this.

Un altro punto qui è che se GetRuleViolations ritorno un IEnumerable di qualcosa, è generalmente molto meglio utilizzare Any() invece di Count() == 0 come si rischia di enumerare l'intera sequenza.

2) La stringa può essere dedotta dall'inizializzazione.

3) Il resharer preferisce var su tipi specifici.

+0

+1 - Un bel consiglio per usare Any() grazie –

0

primo: ReSharper è chiesto informazioni sulla rimozione this, che è solo una cosa stile per me. Niente di più, tenerlo non danneggerà le prestazioni in alcun modo. È solo una questione di leggibilità.

Per il secondo e il terzo: il reharer normalmente preferisce utilizzare var invece del tipo di dati specifico, ecco perché i suggerimenti. Credo che sia una questione di scelta personale e non fornisce guadagni extra oltre alla leggibilità.

0

Il primo non mi sembra chiaro. Di solito non è necessario prefisso this. finché non ci sono ambiguità, che non posso dire da questo esempio. Il resharper ha probabilmente ragione. Gli altri due non miglioreranno le prestazioni, il risultato compilato sarà lo stesso. È solo una questione di gusti e, naturalmente, le tue linee guida sulla codifica.

0

Il primo deve essere configurabile. Per quanto mi ricordo, puoi dire a ReSharper se vuoi avere "questo". di fronte solo a campi, metodi, entrambi o nessuno.

L'utilizzo di "var" non cambierà nulla nel codice CIL generato, quindi le prestazioni rimarranno le stesse. Non ho usato ReSharper per un po 'di tempo e non so perché promuove i tipi anonimi in modo così aggressivo, ma un vantaggio di "var" è che è più resistente ai cambiamenti.

Significato se, anziché chiamare Method.GetNumber(), hai chiamato un wrapper, ad es. Filtro (Method.GetNumber()) nella stessa riga che restituisce un Nullable, non sarà necessario aggiornare il tipo della variabile.

1

Penso che il primo sia per lo scopo, se si desidera rendere "GetRuleViolations()" un metodo statico. Quindi non devi rimuovere l'identificatore "questo".

2

Per il 3 ° - quello che mi infastidisce di più. Fornisce al lettore meno informazioni e penso che sia solo questione di mostrare una caratteristica nuova.

direi - uso var quando si conosce il tipo di ritorno e utilizzare il tipo di oggetto corretto quando non ti piace questo:

var reader = new XmlReader(.... // Implicit 
XmlReader reader = SomeClass.GetReader() // Explicit when you can't be sure 
3

A parte l'ovvio vantaggio del quadratino verde, se si scrive codice che verrà mantenuto da qualcun altro in un secondo momento, è consigliabile non utilizzare le proprie preferenze personali nella sintassi di codifica. Resharper sta diventando utile nella formattazione del codice in un modo che è riconoscibile per un pubblico molto ampio.

Appartengo alla scuola di pensiero che dice che non importa chi ha ragione. Se ci atteniamo a uno schema, troveremo più semplice leggere il codice degli altri.

Quindi, a mio modesto parere, non modificare le impostazioni di reimpostazione di default. Accetti solo che se usi i valori predefiniti, rendi la vita semplice per tutti.

+1

Sono d'accordo con te sull'uso dei parametri predefiniti. Sfortunatamente da quello che ho visto, non mi piacciono le impostazioni predefinite di Resharper –

+1

Cambiare sempre l'impostazione 'var' del resharper in tipo esplicito a causa di SECURITY. Leggibile, va bene, ma può causare gravi danni dopo un refactoring. – Offler

0

Nessuno di questi avrà alcun effetto sulle prestazioni, solo sulla leggibilità.

I suggerimenti 1 e 2 sono più leggibili e 3 meno leggibili del codice originale.

Tuttavia, non è necessario seguire questi suggerimenti se, ad esempio, li trovi meno leggibili o se violano lo standard di codice del codice aziendale. Quando posizioni il cursore sulla linea ondulata, premi Alt-Invio per visualizzare l'elenco delle azioni Contex. Uno di questi sarà modificare la severità dell'ispezione; non puoi mostrarlo affatto o mostrarlo come un suggerimento. È possibile trovare un elenco completo di ispezioni al ReSharper | Opzioni | Controllo del codice | Ispezione Gravità.

Problemi correlati