Mi sono trovato di fronte a questa domanda dal mio capo squadra.
Istruzione 1 (scritta da me):
lnkbtn1.visible = lnkbtn2.visible = lnkbtn.visible = false;
Istruzione 2 (scritta dal mio caposquadra):
lnkbtn1.visible = false;
lnkbtn2.visible = false;
lnkbtn3.visible = false;
Quale affermazione è migliore e perché?
La differenza di prestazioni sarà così incredibilmente scarsa che non dovresti mai nemmeno pensarci.
L'unica cosa che conta qui è quello che preferiresti usare.
La prima opzione potrebbe essere in una riga ma i oneliner non sono necessariamente migliori. È più difficile da leggere e il tuo approccio significa anche che se vuoi avere false-true-false, devi ridigitare tutto.
La seconda opzione è molto chiara e ogni affermazione è autonoma, vorrei andare con questo.
Non c'è alcuna differenza nelle prestazioni. Verranno compilati in modo praticamente identico a IL 1 .
Tuttavia, c'è una differenza nella leggibilità e nello stile del codice. La prima opzione potrebbe essere più compatta, ma la seconda è chiara e conforme alla maggior parte delle linee guida di codifica .NET. Personalmente preferisco il secondo.
1. Ho eseguito un semplice test su LINQPad. L'unica differenza tra le due opzioni era il modo in cui il valore false è stato caricato nello stack tra le chiamate a set_Visible . La prima opzione ha prodotto un ldc.i4.0 e due dup mentre il secondo ha prodotto il tre% di% dei% di _.
Che ne dici di una versione più DRY, in cui anche il codice visible = non viene ripetuto più e più volte?
foreach(var btn in new[]{lnkbtn1, lnkbtn2, lnkbtn3})
btn.visible=false;
IMHO che scalerà meglio quando aumenta il numero di pulsanti o aumenta il numero di proprietà di ciascun pulsante che deve essere inizializzato.
Devo dire che preferisco la prima opzione. È chiaro che tutti i valori sono impostati su false.
Con la seconda opzione dovrò leggere ogni riga e mi chiedo perché non è tutto su una riga che segue DRY principi a causa del letterale ridondante.
Troverei difficile giustificare il secondo caso sulla base del fatto che i valori potrebbero cambiare in futuro. Così tanto codice cruft avviene a causa di qualcosa che il programmatore pensava potesse accadere ma non lo fece mai. Questo codice deve quindi essere testato e mantenuto. Per non parlare di essere letto da potenzialmente dozzine di programmatori nel corso della sua vita.
Solo perché qualcuno è un "caposquadra" non significa molto.
Se .visible non è altro che una semplice variabile booleana, la differenza di costo è zero o sostanzialmente nulla.
Tuttavia, se .visible è una proprietà, tutte le scommesse sono disattivate.
L'assegnazione a una proprietà è una chiamata al metodo e il recupero del valore è un'altra.
In tal caso, i compiti separati potrebbero essere più veloci, ma attenzione per un altro problema.
Le proprietà hanno alcune buone proprietà (!), Ma le ho viste trattate come se fossero libere, dal punto di vista delle prestazioni, quando in realtà possono essere i principali sink-hole del tempo di CPU se vengono implementati in modo ricorsivo.
In termini di stile, ho una visione poco chiara di questo più di un nanosecondo di pensiero. Quasi tutti i software seri hanno problemi ben più grandi di questo.
Leggi altre domande sui tag c# performance