Devo scrivere codice compatto o codice con molti spazi? [duplicare]

15

Ho due amici che hanno scuole di pensiero completamente diverse su come definire il loro codice.

Il primo dice che il codice dovrebbe essere ben indentato e usare molti spazi e nominare le variabili in maniera giudiziosa per organizzare le cose in modo da poter immediatamente capire la gerarchia e la semantica del codice.

Ecco un esempio di come appare il suo codice:

var Stack = function () {

    var pair = function ( first ) {
        return function ( second ) {
            return function ( dispatcher ) {
                return dispatcher ( first ) ( second );
            };
        };
    };

    var getFirst = function ( pair ) {
        return pair ( function ( x ) {
            return function ( y ) {
                return x;
            };
        } );
    };

    var getSecond = function ( pair ) {
        return pair ( function ( x ) {
            return function ( y ) {
                return y;
            };
        } );
    };

    var emptyStack = function () {
        return function () {
            return null;
        }
    };

    var stack = emptyStack ();

    var self = {
        push: function ( item ) {
            stack = pair ( item ) ( stack ); 
            return self;
        },
        pop: function () {
            var top = getFirst ( stack );
            stack = getSecond ( stack ) || emptyStack ();
            return top;
        },
        top: function () {
            return getFirst ( stack );
        }
    };

    return self;
};

Il secondo dice che è meglio avere il tuo codice scritto in modo più compatto in modo che tu possa vedere una parte più grande dell'immagine contemporaneamente e essere in grado di riconoscere più immediatamente come una parte di il programma ne influenzerà un altro.

Ecco lo stesso programma scritto nel suo stile:

var Stack=function(){
var pair=function(x){return function(y){return function(f){return f(x)(y)}}};
var fst=function(p){return p(function(x){return function(y){return x}})};
var snd=function(p){return p(function(x){return function(y){return y}})};
var empt=function(){return function(){return null}};var stk=empt();
var slf={push:function(val){stk=pair(val)(stk);return slf},
pop:function(){var top=fst(stk);stk=snd(stk)||empt();return top},
top:function(){return fst(stk)}};return slf}

Personalmente preferisco scrivere il codice nel primo modo, ma non ho provato molto il secondo modo, quindi forse non ci sono abituato.

Ho notato che quando guardo il codice Javascript della maggior parte dei siti web professionali, di solito usano il secondo stile, quindi potrebbe esserci qualcosa.

Oltre alle semplici preferenze stilistiche soggettive, c'è un motivo per preferire l'una rispetto all'altra?

    
posta Peter Olson 23.05.2013 - 16:55
fonte

7 risposte

17

Dovresti usare il primo approccio perché scala a programmi più grandi.

La mentalità di "Ho bisogno di vedere come tutto influisce su tutto" è dannosa per lo sviluppo del software. Desiderate funzioni / oggetti disaccoppiati, in modo da poter cambiare una cosa senza rompere un'altra funzione distante / non correlata.

Anche se utilizzi uno stile di codifica compatto, alla fine avrai più codice di quello che può essere contenuto sullo schermo contemporaneamente.

Una soluzione migliore (da Clean Code di Robert Martin) è quella di elencare prima le funzioni pubbliche di "alto livello" e fare in modo che ogni funzione mantenga un livello di dettaglio.

    
risposta data 23.05.2013 - 18:14
fonte
2

La maggior parte degli IDE consentirà di comprimere il primo campione in 8 (o anche 1) linee di piccole dimensioni, in modo da poter vedere l'immagine grande. Il secondo campione, al contrario, non può essere fatto per apparire facilmente come il primo.

Il primo campione è più facile da capire, soprattutto per i principianti. Rivela la gerarchia e la sequenza delle azioni eseguite. Inoltre i neofiti dell'IMO preferirebbero avere difficoltà a cogliere il secondo campione in una volta, perché sembrano piuttosto "spaventosi" e complicati.

Quindi, se lavori in un ambiente di professionisti più o meno esperti, preferirei il secondo esempio _ se sei abituato a quello stile, puoi cogliere l'intera idea in un colpo d'occhio. Ma poiché in realtà pochissimi (se ce ne sono) ambienti di sviluppo composti solo da sviluppatori esperti, il primo campione è migliore.

P.S. se non ti piace scrivere tutti quegli spazi e le nuove linee manualmente, potresti avere uno strumento automatico per questo.

    
risposta data 23.05.2013 - 17:22
fonte
2

Generalmente scrivo codice indentato, simile al # 1, ma con meno righe vuote. I rientri consentono di rilevare facilmente i problemi con parentesi. Questo, combinato con ogni incarico sulla propria linea, rende le cose più facili da leggere. Il completamento delle schede consente l'uso di nomi di variabili più lunghi senza digitare troppo.

Sì, è più lungo, ma non c'è nulla di sbagliato nella scrittura del codice lungo. Proprio come sto usando i paragrafi di questa risposta per facilitare la lettura, perché non fare lo stesso nel tuo codice? Dal momento che l'interprete non conosce la differenza *, l'unica persona che beneficia è te.

Emacs ha un plug-in VHDL che uso quotidianamente per abbellire automaticamente il codice tramite una scorciatoia da tastiera. Ciò consente di concentrarsi maggiormente sulla codifica invece di dedicare tempo alla formattazione.

* dipendente dalla lingua. Alcuni linguaggi, come python, usano i rientri come parte della sintassi, nel qual caso l'interprete fa conosce la differenza.

    
risposta data 23.05.2013 - 17:49
fonte
1

Sono d'accordo con ciò che superM ha detto. I miei due centesimi:

Preferisco il primo (non in questo estremo) perché in questo modo posso mantenere il codice molto più facilmente. Anche se dovessi cambiare il mio codice da 6 mesi fa, non comprenderò il secondo stile veloce come il primo.

Ciò che vedi in JavaScript è stato probabilmente scritto in un modo più umano e anche con commenti, ma alcuni semi-compilatori hanno apportato alcune modifiche meccaniche (come la riduzione del nome di una variabile da usersFacebookID a a e l'eliminazione di tutti Commenti). Ciò riduce la quantità di dati inviati a un utente, e questo è il principale collo di bottiglia delle app Web, quindi il sito sembra caricarsi più velocemente. (E l'utente finale comunque non si preoccupa dello stile dei codici).

    
risposta data 23.05.2013 - 17:57
fonte
1

Se il tuo IDE non supporta l'analisi e il piegamento per la tua lingua, allora forse una forma più concisa sarebbe in ordine, ma nel complesso sarà più difficile raccogliere errori. La densità delle informazioni è così alta che potresti facilmente superare qualche errore. Oltre a ciò, la lunghezza delle linee diventerebbe piuttosto lunga nei casi in cui è necessario effettuare più chiamate in una funzione, il che richiederebbe lo scorrimento laterale. (molto più fastidioso quindi scorrendo verso il basso, che è ciò che la maggior parte dei nostri IDE sono progettati per fare) Se stai usando un linguaggio di scripting che verrà interpretato invece di compilato, allora dovresti usare un minificatore prima di spedirlo. L'uso di un minificatore è una pratica comune nelle aziende di sviluppo web quando si utilizza JS per motivi di larghezza di banda. Nelle lingue interpretate lo spazio bianco è rumore. I compilatori di solito rimuovono gli spazi bianchi eccessivi quando concedono il tokenize al codice sorgente, lasciando solo le informazioni utili dopo l'elaborazione. (o al codice byte o al linguaggio macchina) I compilatori devono fare i conti solo una volta. Gli interpreti devono fare i conti con il rumore ogni volta. (Anche se la maggior parte di loro ha qualche tipo di memorizzazione nella cache per alleviare il problema in questi giorni.)

Alla fine dipende dalla piattaforma che utilizzi per modificare la tua fonte e la lingua / l'ambiente in cui intendi utilizzare il tuo codice, ma voterei per l'opzione 1.

    
risposta data 23.05.2013 - 18:15
fonte
1

Sono d'accordo con Friend 1

Da un punto di vista del compilatore, non ha importanza ... e l'opzione 2 ti farà risparmiare solo pochi byte di dimensione del file sul tuo disco rigido gigaByte

Dal punto di vista umano, non importa a te in che modo usi oggi, come sai quello che hai scritto.

Ma quando ritorni ad esso in un giorno, settimana, mese o anno - o qualcun altro ritorna, l'Opzione 2 sarà molto meno leggibile e molto meno comprensibile.

    
risposta data 23.05.2013 - 20:34
fonte
0

Non fare mai l'estremo! Preferirei scrivere

var Stack=function(){
    var pair=function(x){return function(y){return function(f){return f(x)(y)}}};
    var fst=function(p){return p(function(x){return function(y){return x}})};
    var snd=function(p){return p(function(x){return function(y){return y}})};
    var empt=function(){return function(){return null}};
    var stk=empt();
    var r={
        push:function(val){stk=pair(val)(stk); return r},
        pop:function(){var top=fst(stk); stk=snd(stk)||empt(); return top},
        top:function(){return fst(stk)}
        };
    return r}

È compatto e leggibile.

    
risposta data 23.05.2013 - 17:53
fonte