È bello usare variabili locali aggiuntive, tecnicamente superflue, per descrivere cosa sta succedendo?
Ad esempio:
bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);
if(easyUnderstandableIsTrue)
{
// ...
}
Quando si tratta di spese generali tecniche, mi aspetto che il compilatore ottimizzi questa linea aggiuntiva. Ma è considerato un codice inutile gonfio? Ai miei occhi riduce il rischio di commenti obsoleti.
Qual è il costo di avere una variabile aggiuntiva? Nella maggior parte delle lingue, nessuna, sia in lingue compilate che interpretate.
Qual è il vantaggio di questo?
Analogamente all'estrazione dell'espressione booleana criptica in un metodo separato, sei riducendo il rischio di codice duplicato , ma leggermente inferiore rispetto a un caso di un metodo separato. Se l'espressione condizionale viene riutilizzata all'interno del metodo stesso, sarai in grado di riutilizzare la variabile; se l'espressione appare in un metodo diverso, non lo farai.
Nota che, a meno che il tuo linguaggio di programmazione ti permetta di avere variabili locali immutabili o se hai un modo per far rispettare, in termini di stile, che nessuna delle variabili sia riassegnata, tale refactoring potrebbe essere rischioso a lungo termine. Se il valore della variabile viene modificato, potrebbe essere molto difficile ragionare sul codice.
Stai riducendo il rischio che la documentazione non sia sincronizzata con il codice . Gli sviluppatori tendono ad aggiornare i nomi di variabili e metodi più facilmente rispetto ai commenti.¹ Pertanto, non è raro vedere codice come:
// Find if the user is an actual author in order to allow her to edit the message.
if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))
L'espressione probabilmente è iniziata con if (message.author == currentUser) , quindi si è evoluta per gestire il caso di messaggi bloccati e amministratori che non hanno bisogno di essere autori e non si preoccupano delle cose bloccate; tuttavia, il commento non ha riflesso nessuno di questi cambiamenti.
Entrambi i vantaggi non sono particolarmente importanti, ma dato il basso costo di variabili aggiuntive, puoi davvero considerare di usarli.
Si noti che se l'espressione booleana diventa eccessivamente complessa: ²
L'esempio sopra diventa:
class Message
{
...
public boolean canBeEditedBy(User user)
{
...
if (user.isAdministrator) {
return true;
}
return this.author == user && !this.locked;
}
}
...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
...
}
¹ Fonte: la mia personale osservazione dei miei colleghi che sviluppa principalmente software aziendali; YMMV. Una vera ricerca può mostrare risultati diversi. Personalmente, suppongo che quando gli sviluppatori leggono il codice, si concentrino sul codice e i commenti siano documentazione, non codice; di conseguenza, di solito non leggono i commenti, quindi sarebbe difficile aspettarsi che li aggiornino.
² La soglia eccessivamente complessa viene definita con una formula semplice: se la metà degli sviluppatori che esaminano il tuo codice esprime l'intenzione di ucciderti, la soglia viene raggiunta. L'espressione booleana sopra è abbastanza semplice da richiedere il refactoring; tuttavia, quattro parti in una riga if ((a && b) || (c && d)) lo renderebbero potenzialmente riscrivibili. Nota che se l'espressione è piatta, il numero di parti è per lo più irrilevante: if (a || b || c || d || ... || z) è sufficientemente leggibile.
Leggi altre domande sui tag coding-style comments