Qual è il vantaggio del codice a breve leggibile se si vedono solo funzioni e classi all'esterno?

how exactly the methods and properties were written you do not care about, as long as they do what they promise to do.

Esattamente. Ma non appena non fanno quello che promettono di fare, devi andare a controllare il codice per capire perché non lo fanno. Entrare nel codice del tuo collega può rivelare un codice semplice, chiaro e ben scritto, nel qual caso sarai felice. O sarà un mostro da 4 000 LOC, nel qual caso, sarai sfidato .

Questo non si applica esclusivamente al codice che potresti potenzialmente modificare. In diverse occasioni, ho dovuto immergermi nel codice proprietario di .NET Framework, perché non si comportava secondo le mie aspettative. In questi casi, la possibilità di vedere un codice scritto molto bene mi ha permesso di capire in pochi minuti che le mie aspettative erano sbagliate.

So I was wondering if it truly matters when code is short and readable

Se il codice mai non viene letto da nessuno, non importa. Pertanto, se stai scrivendo uno script per automatizzare un'attività, e sai che non appena viene eseguita l'attività, dovrai lanciare lo script, non c'è motivo di perdere tempo con la qualità del codice. Hack qualcosa il più rapidamente possibile; se funziona, è grandioso.

Nella maggior parte dei casi, tuttavia, il codice viene letto molto più frequentemente di quanto non sia scritto, rendendo indispensabile scrivere un codice leggibile.

Now I know a lot of developers do not comment their code. In these cases you do benefit from short readable code. However as long there is the opportunity to document code I am not convinced.

Puoi:

• Scrivi un codice non chiaro che deve essere commentato affinché qualcuno possa capirlo. È probabile che il prossimo che modifica il codice dimenticherà di modificare il commento, il che significa che il commento sarà obsoleto.

• Scrivi un pezzo di codice non chiaro, pensa a un modo migliore per farlo e rifattalo in un pezzo di codice chiaro.

Vedi anche:

• Cosa c'è di sbagliato nei commenti che spiegano codice complesso?

• Come posso trattare con un membro del team che non ama scrivere commenti nel codice?

Per prima cosa, separa il problema del codice funzione dal codice leggibile. Mentre la brevità può contribuire alla leggibilità, non lo garantisce. Né garantisce l'efficienza dell'esecuzione.

So I was wondering if it truly matters when code is short and readable and my enthusiasm about Python and Haskell is justified because there are lots of situations (in professional software development) were you see code only from the outside.

Ogni sviluppatore indossa due cappelli: uno scrittore di codice e un consumatore del codice di un altro programmatore.

Come consumatore di codice, non mi interessa in quale lingua è scritto il codice che impongo, né mi interessa quali siano gli standard di codifica che impongono. Mi interessa solo poterlo chiamare da qualsiasi lingua in cui sto lavorando, che il codice soddisfi i miei requisiti, sia corretto e sia mantenuto attivamente.

Tuttavia, come scrittore di codice, ho lavorato su progetti che hanno avuto più versioni nell'arco di decenni. Migliaia di altri sviluppatori consumano il nostro codice. Una delle discipline che lo rende possibile è che i miei colleghi e io do si preoccupano che il nostro codice sia leggibile. Ogni giorno devo revisionare il codice che io o qualcun altro nella mia squadra ho scritto 7 anni fa.

Se scrivi degli script che vengono usati una volta e non vengono mai più toccati, potresti pensare che la leggibilità non sia importante. Ti sbaglieresti, perché tutti gli script tranne quelli più banali devono essere sottoposti a debug per farli funzionare correttamente. Il debug di un codice leggibile è molto più semplice del debug di codice oscuro.

Ad esempio, se si utilizza il pacchetto SciPy in Python probabilmente si chiameranno funzioni che chiamano a loro volta funzioni da Sottoprogrammi di Algebra lineare di base (BLAS), una libreria di routine di manipolazione di matrici scritte in FORTRAN. Come utente di SciPy, non mi interessa davvero quali sono i loro standard di leggibilità. Ma i responsabili di mantenere BLAS si preoccupano profondamente di quanto sia leggibile il loro codice, perché sono loro che hanno dovuto mantenere quel codice per quasi 40 anni.

Now I know a lot of developers do not comment their code. In these cases you do benefit from short readable code. However as long there is the opportunity to document code I am not convinced.

Poiché inevitabilmente il codice e i commenti non verranno sincronizzati, ad esempio qualcuno modificherà il codice e trascurerà di aggiornare i commenti. Quindi i futuri manutentori dovranno capire sia i commenti che il codice, e capire se i commenti, il codice o nessuno dei due, è la versione corretta di ciò che dovrebbe accadere. Uso i commenti e cerco di essere disciplinato sull'aggiornarli, ma vi assicuro che anche con le migliori intenzioni, verranno a divergere. Se il tuo codice non è leggibile, smistare le cose sarà inutilmente doloroso.

However with languages like Java, C++ and C# most of the time you deal with code "from the outside".

La maggior parte del codice che uso, mi occupo da fuori.

La maggior parte del codice che scrivo, fisso o refactor, mi occupo da dentro.

La maggior parte del codice che uso, io uso in un split secondo.

La maggior parte del codice che scrivo, correggi o refactoring, trascorro almeno alcuni minuti e, a volte, molte ore.

Quindi, la maggior parte delle volte mi occupo di codice dall'interno, perché mentre il codice con cui ho a che fare da dentro è una minoranza del codice che in qualche modo "tratta" è il codice che la maggior parte di ciò che "tratta" viene spesa su.

Sto presumendo che il codice che scriverai verrà utilizzato da altri. Se necessario, sarà necessario mantenerlo e / o esteso. La leggibilità e le dimensioni del codice sono parametri chiave per ottenere quelle proprietà desiderate come manutenibilità e estensibilità e buone pratiche come il riutilizzo del codice durante la scrittura del codice. Esistono numerosi vantaggi della scrittura di codice estensibile ed ispezionabile con la più importante ed importante facilità di potenziali modifiche e in generale la gestione di alcune parti di esso. Rende più semplici i tuoi partener e la tua vita quando arriva il momento di modificare l'implementazione, la struttura, il comportamento e di fornire l'opzione di aggiungere nuove parti su di esso.

Naturalmente ci saranno casi in cui devi sacrificare la leggibilità per l'efficienza, ma nella maggior parte delle situazioni dovresti essere in grado di trovare uno sweet spot tra questi due.

Se invece il tuo codice è un casino (enorme e difficile da leggere) dovresti passare troppo tempo e tempo; sforzo in processi come il debugging o il refactoring, che non penso sia la cosa più piacevole da affrontare. C'è un detto che adoro che va come

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability."

Pensando anche all'open source, è una buona pratica scrivere un codice leggibile, in modo che altri possano capire, contribuire e migliorare il software (per trarne il meglio) e per essere in grado di raccogliere nuovi stili di codifica: pratiche altrui. Se il codice è autoesplicativo, elimini anche la necessità di documentazione non necessaria.

Anche nel caso in cui desideri semplicemente utilizzare un particolare software ( "essere all'esterno" ), sarebbe opportuno per te riuscire a rintracciare il modo in cui funziona, al fine di evitare comportamenti imprevedibili, e scegliere ciò che meglio si adatta al tuo scopo se hai più opzioni (es. librerie).

IMHO è meglio pensare con più impegno e semplificare il codice, perché oltre a scrivere un software migliore ti aiuta anche a migliorare nel modo in cui pensi e risolvi i problemi.

Quindi ti chiederei perché non farlo, se ti rende la vita migliore e quella di tutti gli altri più facile?