Preferisci concisione o leggibilità nel tuo codice? [chiuso]

Le scorciatoie di lingua possono spesso essere utilizzate per rendere il codice più conciso.

Ad esempio, gli operatori di coalescenza ternari e nulli possono ridurre la quantità di codice, ma probabilmente a scapito della leggibilità:

In C #:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

è funzionalmente equivalente a:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

ma ovviamente molto più dettagliato.

Dove traccia la linea quando si tratta di concisione vs leggibilità?

Tutti e due.

Il tuo primo esempio è sicuramente più dettagliato, e probabilmente più esplicito ... ma mi richiede anche di scansionare cinque righe anziché una. Peggio ancora, sottolinea il suo scopo: assegnare un valore a newGuy.Boss.

Il tuo secondo esempio potrebbe costarmi un secondo se non ho familiarità con l'operatore di coalescenza nulla, ma non ci possono essere dubbi sul suo scopo e se sto eseguendo una scansione di una routine più ampia alla ricerca della fonte di un valore, lo farà essere molto più facile per me scegliere questo.

Ora, contrapponi questo:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

...con:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

Il secondo esempio è di nuovo molto più breve, ma ora ne oscura lo scopo facendo apparire distinti i compiti attivati ​​dallo stesso test. Qui, sento che la verbosità del primo è giustificata.

Mentre entrambi sono buoni obiettivi, mi schierò sempre con Readability quando sono costretto a sceglierne uno.

Direi che il tuo esempio migliora sia la leggibilità che la brevità. Considera, tuttavia:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

al contrario di

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

Quest'ultimo è conciso, ma è difficile da leggere. Il primo è dettagliato, ma il flusso della logica è chiaro.

In definitiva, la brevità non ha molto a che fare con uno scopo, oltre alla capacità di adattarsi maggiormente allo schermo. La leggibilità semplifica il debug e quindi dovrebbe essere generalmente preferita.

Direi che una regola generale non sacrifica mai la leggibilità a causa della concisione, ma mai giudicare la leggibilità sulla base della mancanza di conoscenza di un altro programmatore su tale argomento.

Concisione e leggibilità non sono opposti. Come questa risposta, a volte più breve è più leggibile.

Direi che preferisco la leggibilità, anche se a volte ciò significa usare un codice conciso. (Vale a dire ternario per condizionali relativamente semplici all'interno di un blocco condizionale più grande.)

Fondamentalmente, se è inutilmente difficile da capire, non farlo.

La leggibilità viene prima dove è in conflitto con la concisione, perché il codice viene modificato più spesso di quanto sia inizialmente scritto. D'altro canto:

1. Il rumore sintattico e il codice della caldaia spesso oscurano le intenzioni e quindi danneggiano la leggibilità. A volte il codice più conciso è anche più leggibile. Ad esempio, pensa alle funzioni lambda o ai delegati / funzioni di prima classe rispetto alle classi a metodo singolo che implementano un'interfaccia a metodo singolo.

2. La leggibilità dovrebbe essere valutata in base alla facilità di lettura del codice per un programmatore abbastanza esperto che conosce abbastanza bene la lingua e le sue caratteristiche uniche / avanzate, non qualche scimmia di codice a malapena competente che conosce solo il minimo comune denominatore.

Un aspetto che non credo sia stato ancora menzionato: quali sono i tuoi obiettivi?

Se tutto ciò che ti interessa è la sicurezza del lavoro, cerca concisione e compattezza su tutto il resto. Passa anche a commentare il tuo codice.

Se vuoi essere in grado di distribuire facilmente il tuo codice a qualcun altro mentre lavori su un nuovo progetto interessante, vai per leggibilità, chiarezza e molti commenti solidi.

_{^{Nota: quanto sopra non riguarda te personalmente, @Damovisa; è per chiunque scelga tra le due posizioni.}}

C'è una cosa che la versione dettagliata ha come vantaggio.

Ha più linee e la maggior parte dei debugger sono orientati alla linea ! È molto difficile impostare un punto di interruzione nel mezzo di un'espressione, ma di solito è banalmente semplice impostarlo all'interno di un'istruzione di blocco.

In altre parole, quale vorresti vedere nel tuo editor se vuoi che il tuo debugger inizi quando boss == null?

(Detto questo mi piace l'operatore ?? -)

La leggibilità dovrebbe venire prima di tutto, a lungo termine la maggior parte delle persone trascorre la maggior parte del tempo a modificare o estendere il codice esistente: la leggibilità è una parte importante della manutenibilità.

Detto questo, la concisione è qualcosa che può contribuire alla leggibilità. Ad esempio, nella tua domanda il secondo frammento è sia più leggibile sia più conciso.