La semplicità migliora sempre la leggibilità?

Di recente, stavo sviluppando una serie di standard di codifica per la nostra azienda. (Siamo una nuova squadra che si dirama in una nuova lingua per l'azienda.)

Nella mia prima bozza, ho fissato lo scopo dei nostri standard di codifica come migliorare la leggibilità, la manutenibilità, l'affidabilità e le prestazioni. (Ho ignorato la scrivibilità, la portabilità, i costi, la compatibilità con gli standard precedenti, ecc.)

Uno dei miei obiettivi durante la stesura di questo documento è stato quello di far passare l'idea della semplicità del codice. L'idea era che ci dovrebbe essere solo una chiamata di funzione o operazione per linea. La mia speranza era che ciò aumentasse la leggibilità. È un'idea che ho riportato dalla nostra lingua precedente.

Tuttavia, ho messo in dubbio il presupposto dietro questa spinta:

La semplicità migliora sempre la leggibilità?

Esiste un caso in cui la scrittura di un codice più semplice riduce la leggibilità?

Dovrebbe essere ovvio, ma per "più semplice" non intendo "più facile da scrivere", ma meno cose in corso per riga.

"Semplice" è una parola abusata. "Leggibile" può essere definito proficuamente come "semplice da capire", nel qual caso aumentare (questa misura di) semplicità per definizione aumenta la leggibilità, ma non penso che questo significhi. Ho scritto su questo altrove , ma in generale qualcosa può essere chiamato "semplice" o per essere più astratta (in questo caso un minor numero di concetti possono esprimere più fenomeni) o per essere più concreto (nel qual caso un concetto non richiede tanto di sfondo conoscenza da comprendere in primo luogo). Sto sostenendo che, a seconda della prospettiva, un concetto più astratto può ragionevolmente essere definito più semplice di un concetto più concreto, o viceversa . Questo, anche se "astratto" e "

Userò come esempio del codice Haskell che ho scritto qualche tempo fa. Ho fatto una domanda su StackOverflow sull'utilizzo della monade Elenco per calcolare un contatore in cui ogni cifra potrebbe avere una base diversa. La mia eventuale soluzione (non conoscendo molto Haskell) sembrava:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Una delle risposte ha ridotto questo a:

count = mapM (enumFromTo 0)

Quale di questi è "più semplice" da capire (cioè più leggibile) dipende interamente da quanto il lettore abbia acquisito confidenza con le operazioni (astratte) monadiche (e, per tale motivo, codice privo di punti). Un lettore che è molto a suo agio con questi concetti astratti preferirà leggere la versione (breve) più astratta, mentre uno che non è a proprio agio con tali operazioni preferirà leggere la versione (lunga) più concreta. Non esiste una risposta su quale versione sia più leggibile che valga per tutti.

Se lo standard di codifica riguarda "Leggibilità, manutenibilità, affidabilità e prestazioni", basta affermarlo .

Non cercare di prescrivere come raggiungere queste cose in quanto ci saranno sempre situazioni in cui c'è un contro esempio.

Ciò che devi prescrivere sono le cose che causeranno la rottura del codice se non rispettate. I tratti stilistici non infrangono il codice e dovrebbero essere suggerimenti (fintanto che la maggior parte del team concorda sul fatto che è leggibilità, il resto dovrebbe essere la preferenza dello sviluppatore (con revisione del codice in modo che la pressione dei pari ricordi alle persone che altre persone devono leggere il codice)) .

Meno "cose ​​per riga", semplicità e leggibilità non sono la stessa cosa. Si può prendere un algoritmo non documentato oscuro incredibilmente complicato e codificarlo con 1 istruzione per riga anziché 2, e non diventerà molto più leggibile.

Meno "roba per linea" potrebbe anche richiedere agli sviluppatori di grandi monitor alti per vedere i blocchi di codice ora distribuiti in modo più verticale. O causare affaticamento degli occhi dalla lettura di caratteri più piccoli.

La leggibilità è la propria metrica, che spesso richiede un compromesso tra molte altre metriche più facilmente misurabili. Pre-vincolare tutte quelle altre metriche e il compromesso non diventa più possibile, con conseguente codice meno leggibile.

Sempre? - NO

Ironia della sorte, raggiungere il giusto livello di semplicità può essere un'impresa complessa. Penso che la chiave sia con moderazione. La semplicità può anche essere negli occhi di chi guarda, quindi se ti ritrovi a pensarci troppo, lascialo da solo o torna più tardi.

Personalmente, quando provo a tornare indietro e semplificare qualcosa che ho scritto, mi concentro su aree in cui ho cambiato idea o ho provato un paio di cose per ottenere quello che volevo. Di solito queste aree possono essere levigate. Quindi fai solo un paio di passaggi attraverso il codice per renderlo più leggibile senza distribuire le cose così tanto che stai saltando dappertutto per capire cosa sta succedendo in un debug.

Se vado per semplicità, posso scrivere codice in questo modo:

10000000000000000000000000000000000000000000

Ma se vado per leggibilità, preferirò questo:

1e43

D'altra parte, 1000è molto più leggibile e semplice rispetto 1e3a quando non si lavora sempre con numeri in notazione scientifica.

Questo è un esempio degenerato di un modello molto più generale che puoi trovare quasi ovunque: costruire qualcosa con blocchi molto semplici può rapidamente diventare illeggibile / inefficiente / cattivo in molti modi diversi. Generalizzare e riutilizzare, d'altra parte, all'inizio è più difficile ("wtf è e?! Intendevano scrivere 1343?" Qualcuno potrebbe dire), ma può aiutare molto nel lungo periodo.

Non necessariamente. Se hai un'operazione complessa, quella complessità deve andare da qualche parte. Ridurre il numero di "cose" che vanno su una riga significa solo che occuperà più linee, il che può effettivamente essere dannoso per la leggibilità del codice se rende la tua routine troppo "alta" per adattarsi su uno schermo.

Chiarezza + Standard + Riutilizzo del codice + Buoni commenti + Un buon design potrebbe migliorare la leggibilità .

La semplicità non è sempre nelle mani dello sviluppatore perché la natura degli algoritmi e la complessità della struttura dell'applicazione in questi giorni.

Prendi le semplici pagine Web che eseguono compiti semplici. Data una routine di ordinamento, non è possibile semplificare la logica, ma è possibile renderlo più chiaro con i commenti, utilizzando nomi di variabili significativi, averlo scritto in modo strutturato, ecc.

La semplicità migliora sempre la leggibilità?

No. Ho visto molti casi in cui fare più cose più semplici su una linea è meno complesso di avere più linee.

C'è un compromesso tra meno codice e codice più semplice.

In generale, consiglierei di cercare un codice più semplice a meno che non sia sicuro che farlo in meno righe sia meglio. Preferirei piuttosto avere un codice "troppo dettagliato" su un codice "troppo complesso".

"Rendi le cose il più semplice possibile, ma non più semplice" - Spesso parafrasi di Albert Einstein

La semplicità migliora tutto . Per diversi valori di semplicità, ovviamente. Sono meno righe di codice? Può essere. È un eseguibile più piccolo? Possibilmente. È qualcosa su cui la tua squadra deve essere d'accordo? Assolutamente .

La semplicità migliora sempre la leggibilità? Sì. Un'istruzione per riga è sempre più semplice? No. Molte lingue hanno un operatore ternario, che, una volta compreso, è più semplice e più facile da comprendere rispetto agli equivalenti compiti if / else.

Nelle lingue che consentono di impostare più variabili su una riga, farlo è spesso più semplice e facile da comprendere rispetto a qualsiasi equivalente.

Un altro esempio: le espressioni regolari fanno molto, in genere in una sola riga, e l'equivalente senza regex è spesso molto più difficile da leggere. / \ d {3} [-] \ d {3} - \ d {4} / è l'equivalente di una chiamata di funzione con almeno alcuni commenti ed è più facile da comprendere rispetto al corpo della funzione corrispondente.

Leggibilità e semplicità sono termini soggettivi che, a seconda della persona e del contesto, di solito ma non sempre vanno insieme.

Un termine più obiettivo è concisione - qualcosa che in linea di principio si può contare contando i personaggi, anche se ci sono alcuni difetti. La concisione sembra implicare semplicità e leggibilità, ma ci sono (almeno secondo me) delle eccezioni.

Un pezzo di codice più lungo (e probabilmente più complesso) può essere più leggibile se esprime meglio l'intento. Se la tua definizione di semplicità si preoccupa dell'intenzione è un'altra cosa soggettiva: potresti definire la complessità in termini di struttura sintattica ed entropia della teoria dell'informazione, per esempio, senza alcun riferimento alle intenzioni.

Quindi, un nome variabile più lungo ben scelto può ...

• Migliora la leggibilità esprimendo meglio l'intento
• Riduci la concisione: dopo tutto è più lungo
• Non hanno alcun effetto sulla semplicità sintattica - la struttura sintattica del codice è invariata

Allo stesso modo, potrei scrivere if (some_boolean == true). In confronto con l'alternativa equivalente if (some_boolean), questo ...

• Riduce la concisione
• Riduce la semplicità sintattica, ma
• Può migliorare la leggibilità esprimendo meglio l'intento.

Naturalmente questo scatenerà una protesta di massa - a molte persone, anche questo danneggia sempre la leggibilità. Per me dipende molto dalla fonte del valore booleano: ad esempio, il nome della variabile (o il nome del metodo o altro) potrebbe non esprimere chiaramente che il valore è "valore della verità". Certo, ifti dice qualcosa, ma profuma ancora. Ma molte persone mi chiameranno un idiota per crederci.

Che è un'ulteriore prova della soggettività generale, ovviamente.

Ti mancano tutte alcune definizioni fondamentali . Semplice, dalla radice sim-plex , significa una piega . Semplice significa fare una cosa . Facile, dalla facilità della radice , significa stare vicino . Facile significa che è a portata di mano . Gli esempi di codice semplice forniti in altre risposte non sono esattamente ciò che appaiono.

Prendi la visualizzazione di rotsor di un valore molto grande. Dice che è semplice . Secondo me, non è semplice. È facile. È a portata di mano per digitare il numero di 0 richiesti.

10000000000000000000000000000000000000000000

La versione leggibile è semplice. Fa una cosa. Esprime il numero descrivendone le dimensioni in uno scopo di notazione creato per questa funzione.

1e43

Potresti descrivere lo snippet di codice "semplice" di Aidan come fare una cosa? Contiene 10 righe di codice (senza contare i commenti) e almeno 7 blocchi (come li conterei). Se segui i commenti, vedresti che fa almeno 4 cose!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Ma una delle raccomandazioni per riscrivere questo codice era una dichiarazione. Aidan afferma che un lettore dovrebbe essere o familiarizzare con le dichiarazioni monadiche, il codice libero del puntatore, ecc. Va bene. Quei concetti sono singolari e indipendenti da imparare.

count = mapM (enumFromTo 0)

Scoprirai che il codice veramente semplice è più leggibile del codice semplice perché fa solo una cosa. Potrebbe essere necessario andare fuori e imparare più "una cosa" per capire il semplice codice. Ma dovrebbe essere sempre più leggibile.

La semplicità migliora sempre la leggibilità?

Direi, forse con un po 'di polemiche, assolutamente no .

Potresti consegnarmi una classe con 200 funzioni membro nella sua interfaccia pubblica, e potrebbe essere l'interfaccia pubblica più umanamente leggibile là fuori. Potrebbe essere una gioia leggere casualmente questo codice e la sua documentazione. Tuttavia, non lo definirei "semplice", perché a dispetto della leggibilità, dovrei preoccuparmi di come tutte queste funzioni interagiscono tra loro e potenzialmente fare attenzione ai casi complicati derivanti da un uso improprio.

Preferirei una classe con 20 funzioni membro che non erano così facili da leggere a 200, perché la "leggibilità" non è la mia priorità in termini di prevenzione dell'errore umano e miglioramento della manutenibilità del codice (la facilità con cui possiamo cambiarlo, cioè).

Tuttavia, tutto ciò dipenderà dalla nostra definizione personale di "semplicità". La "leggibilità" in genere non varia così selvaggiamente tra noi, a meno che qualcuno non abbia acquisito così tanta competenza e fluidità da considerare regex molto "leggibile", ad esempio dimenticando il resto di noi semplici mortali.

Semplicità

C'è stato un tempo, tanto tempo fa, in cui pensavo che "semplicità" significasse "il più facile da leggere possibile". Quindi scriverei il codice C con molte funzioni utili, cercando di migliorare la sintassi e rendere le cose il più facili da leggere e scrivere possibile.

Di conseguenza ho progettato librerie molto grandi, ricche e di alto livello, cercando di modellare una funzione per ogni pensiero umano naturale: aiutanti su aiutanti su aiutanti, tutti per modellare il codice client su una sintassi più leggibile. Il codice che ho scritto allora potrebbe essere stato il più "leggibile", ma era anche il più "non mantenibile" e "complesso".

blesità

Eppure ho avuto una breve passione con LISP verso la metà degli anni '90 (ritardatario). Ha cambiato tutta la mia idea di "semplicità".

LISP non è la lingua più leggibile. Spero che nessuno pensi che l'estrazione di CDR e CAR mentre invoca una funzione ricorsiva con un carico di parentesi annidate sia molto "leggibile".

Tuttavia, dopo aver lottato per farmi avvolgere il cervello dalla strana sintassi della lingua e dai modi totalmente ricorsivi di fare le cose, ha cambiato in modo permanente la mia idea di semplicità.

Quello che ho trovato con il codice che ho scritto in LISP è che non stavo più commettendo errori sottili, anche se la delicatezza di pensare in quel modo mi ha fatto commettere errori più palesi (ma quelli sono facili da individuare e correggere). Non avevo frainteso quello che stava facendo una funzione e mi perdevo un effetto collaterale sottile e imprevisto. Mi stavo solo divertendo in generale a fare modifiche e scrivere programmi corretti.

Dopo LISP, la semplicità per me è diventata minimalismo, simmetria, flessibilità, meno effetti collaterali, meno funzioni ma più flessibili che si combinano in un'infinita varietà di modi.

Sono arrivato ad apprezzare la mentalità secondo cui il codice più affidabile di tutti è il codice che non esiste. Sebbene sia solo una metrica grezza, tendo a vedere il potenziale di inaffidabilità del codice in base alla sua quantità. Cercare la massima praticità e leggibilità sintattiche tende ad aumentare tale quantità di un fattore importante.

minimalismo

Con la mentalità LISP integrata in me, sono arrivato a preferire le API minimaliste. Preferirei una libreria con meno funzioni, ma più affidabili e flessibili, che sono meno convenienti e la potenzialità più difficile da leggere rispetto a una che offre un carico di aiutanti "convenienti" e tale che può rendere il codice facile da "leggere" ma potenzialmente inciampare più problemi con inaffidabilità e sorprese che derivano dall'incomprensione di ciò che fa una di queste migliaia di funzioni.

Sicurezza

Un'altra cosa su LISP era la sicurezza. Promuoveva effetti collaterali minimi e funzioni pure, ed era lì che non mi vedevo più commettere errori impercettibili, anche se la difficoltà di leggere e scrivere nella lingua aumentava errori più palesi che potevo individuare 10 secondi dopo.

Funzioni pure e stati immutabili sono diventati preferibili per me ogni volta che potevo permettermelo, anche se la sintassi di:

sword = sharpen(sword)

... è un po 'meno semplice e distaccato dal pensiero umano rispetto a:

sharpen(sword)

Leggibilità VS. Semplicità

Ancora una volta, LISP non è la lingua più "leggibile". Può racchiudere molta logica in una piccola sezione di codice (probabilmente più di un pensiero umano per riga). Tendo a preferire idealmente un pensiero umano per riga per "leggibilità", ma non è necessariamente per "semplicità".

Con questo tipo di definizione di "semplice", a volte "semplice" potrebbe in qualche modo competere con "leggibile". Questo sta prendendo in considerazione le cose più dal punto di vista della progettazione dell'interfaccia.

Una semplice interfaccia significa che devi imparare molte meno cose per usarlo e potenzialmente ha una maggiore affidabilità e un minor numero di problemi a causa del suo minimalismo. Una documentazione completa sull'argomento potrebbe adattarsi a un opuscolo piuttosto che a un enorme volume di libri. Tuttavia, potrebbe richiedere un po 'più di lavoro grugnito e produrre codice meno leggibile.

"Semplice" per me migliora la nostra capacità di comprendere la funzionalità del nostro sistema ad un livello ampio. "Leggibile" per me migliora la nostra capacità di connettere ogni piccola riga di codice al linguaggio naturale e al pensiero e potrebbe accelerare la nostra comprensione di ciò che fa una riga di codice, specialmente se non siamo fluenti nella lingua.

Regex è un esempio di ciò che considero "estremamente semplice". È "troppo semplice e troppo illeggibile" per i miei gusti personali. C'è un atto di bilanciamento per me tra questi due estremi, ma regex ha quella qualità di semplicità simile a LISP come la definisco io: minimalismo, simmetria, incredibile flessibilità, affidabilità, ecc. Il problema per me con regex è che è così semplice che è diventato così illeggibile al punto in cui non penso che diventerò mai fluente (il mio cervello non funziona in quel modo e invidio le persone che sanno scrivere il codice regex in modo fluido).

Quindi, comunque, questa è la mia definizione di "semplicità", ed è completamente indipendente dalla "leggibilità" e talvolta può persino interferire con l'altro, portando a un atto di bilanciamento tra una libreria più "sintatticamente conveniente" e leggibile ma più grande o una "sintattica scomoda ", meno leggibile, ma ancora più piccola libreria. Ho sempre trovato la vera "convenienza della comprensione" e le vere priorità di "manutenibilità" in linea con quest'ultima, con la forte preferenza per il minimalismo anche a un certo costo per la leggibilità e la sintassi umana più naturale (ma non al punto di regex) . YMMV.

Sempre? - SÌ

Raggiungere il giusto livello di semplicità è un'impresa complessa e difficile. Ma vale sempre la pena poiché migliora sempre la leggibilità. Penso che la chiave sia la comprensione profonda. La semplicità è un assoluto, misurato da "nuovi concetti" per "pezzo" di codice. Alcuni nuovi concetti significa più semplice.

Concentrati sulle aree in cui è presente un denso gruppo di concetti e trova il modo di "frammentare" o "riassumere" o "astratto". Fai un paio di passaggi attraverso il codice per renderlo più semplice e più leggibile.

Una buona astrazione vale il suo peso in oro. Una buona astrazione rende questo più semplice - e di conseguenza più leggibile.

Le domande mi ricordano questa risposta su Stack Overflow, in particolare questa citazione (sostituire la qualità con semplicità):

Qualità: sai di cosa si tratta, ma non sai di cosa si tratta. Ma questo è contraddittorio. Ma alcune cose sono meglio di altre, cioè hanno più qualità. Ma quando provi a dire qual è la qualità, a parte le cose che ce l'hanno, va tutto male! Non c'è niente di cui parlare. Ma se non riesci a dire cos'è la qualità, come fai a sapere di cosa si tratta o come sai che esiste? Se nessuno sa cosa sia, allora per tutti gli scopi pratici non esiste affatto. Ma per tutti gli scopi pratici esiste davvero. Su cosa si basano i voti? Perché altrimenti la gente pagherebbe fortuna per alcune cose e ne getterebbe altre nel mucchio dei rifiuti? Ovviamente alcune cose sono migliori di altre - ma qual è la `` migliore ''? - Quindi vai e vai, girare ruote mentali e in nessun posto trovare un posto per ottenere trazione. Che diavolo è la qualità? Che cos'è?

Penso che sia importante tenere presente che uno standard di codifica codificato per tutti i suoi benefici non renderà buoni programmatori di cattivi. Una parola come "semplice" può essere interpretata in modo diverso da persone diverse (vedi la risposta di Aidan Cully), ma potrebbe non essere una cosa così brutta. I programmatori junior dovranno ancora far rivedere il proprio codice da programmatori senior e capire perché l'interpretazione dei programmatori senior di "semplice" è migliore della propria.

Una chiamata di funzione per linea è più semplice? Facciamo un esempio!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

Cosa pensi? Una chiamata per linea è davvero più semplice?