it-swarm.it

Scrivi davvero 'codice pulito'?

Ho visto alcuni programmatori modificare il loro codice più e più volte non solo per farlo "funzionare bene", ma anche per farlo "apparire bene".

IMO, il "codice pulito" è in realtà un complimento che indica che il tuo codice è elegante, perfettamente comprensibile e mantenibile. E la differenza emerge quando devi scegliere tra un codice esteticamente accattivante rispetto a un codice che è stressante da guardare.

Quindi, quanti di voi scrivono davvero 'codice pulito'? È una buona pratica? Quali sono gli altri vantaggi o svantaggi di questo?

57
ykombinator

Direi che molti di noi non scrivono codice pulito . E in generale, non è il nostro lavoro. Il nostro compito come sviluppatori di software è quello di consegnare un prodotto che funzioni, in tempo.

Mi viene in mente il post sul blog di Joel Spolsky: The Duct Tape Programmer .

Cita da Coders at Work :

Alla fine della giornata, spedisci la cosa f ***** g! È fantastico riscrivere il tuo codice e renderlo più pulito e per la terza volta sarà davvero carino. Ma non è questo il punto: non sei qui per scrivere codice; sei qui per spedire prodotti. - Jamie Zawinsky

Mi viene anche ricordato la risposta del blog di Robert Martin :

Così. Essere intelligenti. Essere pulito. Sii semplice. Nave! E tieni pronto un piccolo rotolo di nastro adesivo e non aver paura di usarlo. - Zio Bob

Se il codice, uno sviluppatore scrive sembra pulito E funziona (è consegnabile), così sia, buono per tutti. Ma se uno sviluppatore sta armeggiando cercando di rendere il codice pulito e leggibile a spese di essere in grado di consegnarlo tempestivamente, allora è un male. Fallo funzionare, usa il nastro adesivo e spediscilo. Puoi riformattarlo in un secondo momento e renderlo super meraviglioso ed efficiente.

Sì, è buona norma scrivere codice pulito, ma mai a scapito di poterlo consegnare. Il vantaggio di consegnare in tempo un prodotto registrato su nastro supera di gran lunga i vantaggi di un codice pulito che non è mai stato completato e consegnato.

Un buon pezzo di codice che ho incontrato non è pulito. Alcuni sono decisamente brutti. Ma sono stati tutti rilasciati e utilizzati nella produzione. Alcuni potrebbero dire che non è professionale scrivere codice disordinato. Non sono d'accordo. La cosa professionale è fornire codice che funzioni, sia pulito che disordinato. Lo sviluppatore deve fare il meglio che può, dato tutto il tempo che è stato assegnato prima della consegna. Quindi, torna a pulire ... è professionale. Si spera che il codice consegnato non sia puro nastro adesivo ed è "abbastanza pulito".

54
spong

È necessario assicurarsi che il codice sia molto leggibile, pulito e gestibile. Questo è quello che fanno tutti i programmatori must.

Ma stai parlando di over styling (come quel termine meglio quel girl-code ) che non serve altro che l'ego del suo autore.

Ho visto molti sviluppatori in passato così orgogliosi della loro creazione (sai, come nei bagni;)), hanno passato ore a pulire e lucidare il loro codice. Alcuni di loro erano così meticolosi da garantire il rispetto degli spazi bianchi corretti tra i membri.

È troppo.

Trovo quel tipo di comportamento controproducente. In un contesto professionale , devi essere professionista . Puoi ottenere la tua soddisfazione scrivendo un codice pulito, molto leggibile e gestibile e parlando con utenti o colleghi felici.

39
user2567

Non sarei d'accordo con la risposta accettata su questa domanda.

La tua responsabilità è ovviamente quella di spedire, ma di solito hai anche la responsabilità di spedire qualcosa che sia mantenibile nel modo più conveniente possibile da te e dai futuri sviluppatori.

Ho trascorso periodi come quel povero programmatore di manutenzione o consulente sul posto che deve capire ed eseguire il debug di un enorme sistema non documentato, e posso dirti che cattivi design e disordinato codice confuso possono portare a ore o addirittura giorni di sforzi sprecati. Sono in grado di pensare a molte situazioni in cui un ulteriore N ore di sforzo da parte dello sviluppatore iniziale avrebbe potuto portare a un risparmio sui costi di 5 N in termini di tempo.

So che esiste una statistica che ruota attorno a questo, ma nella mia esperienza su più progetti, ogni riga di codice che viene scritta viene letta 5-20 volte durante l'estensione e la manutenzione.

Quindi direi ripulisci il codice entro un centimetro dalla sua vita. Ci vuole tempo, ma è probabilmente un risparmio sui costi netti per tutta la durata del progetto.

24
Benjamin Wootton

Qualcuno di noi comprerebbe un'auto se sappiamo che sotto il cofano è tutto disordinato e difficile da risolvere, mantenere o riparare e richiede più risorse per funzionare di quanto dovrebbe?

Perché dovrebbe essere diverso per un software?

Solo perché gli utenti finali non possono guardare sotto il cofano non significa che non lo sapranno mai. Prima o poi comparirà.

Rispondere alla domanda "In realtà scrivi 'clean code'?" -- O si.!

21
Sifar

Se per "codice pulito" intendi fare di tutto per assicurarmi che il codice sia il più chiaro possibile?

Diamine sì.

Più è pulito, più chiaro è il codice, più è facile da mantenere e consente di risparmiare tempo nel lungo periodo. Non guardare al codice pulito come vanità; guardalo come un investimento per risparmiare tempo e sforzi futuri.

18
GrandmasterB

Onestamente dipende. Mi piace il modo in cui tutti spargono la linea del partito su come "qualcosa di meno di un codice pulito e ben documentato è una pura parodia!", Ma lavoro in un'azienda con cicli di distribuzione ridicoli e zero svista: faccio il meglio che posso, ma scrivo così molto codice è estremamente difficile scrivere il codice pulito perfetto che tutti gli altri sostengono che scrivono.

Provo a scrivere un codice che può essere facilmente gestito da qualcuno che ha più o meno le mie capacità. Commento le parti difficili, dai nomi ai programmi, alle variabili e alle classi nomi amichevoli, distribuisco e vado avanti. Non ho tempo di fare nient'altro.

A volte mi sento un po 'in colpa per questo, ma non molto. Dovresti vedere alcuni degli orrori con cui ho a che fare quotidianamente. Decenni di codice personalizzato in lingue oscure con zero documentazione. Uno dei miei colleghi si sviluppa esclusivamente in Visual Basic 6.0 e distribuisce binari con nome crittografico ovunque. La donna che ho sostituito programmava esclusivamente in RPG .

È estremamente difficile per me credere, tanto orribile schifo come ho visto nei miei anni da programmatore, che tutti generano solo codice pulito.

15
Satanicpuppy

Non penso che mi piaccia il termine "codice ragazza", ma codice pulito = codice gestibile. Niente di meno è poco professionale.

Come regola generale, considero il prossimo sviluppatore che deve guardare al mio casino.

Molte volte sono io ... diversi mesi dopo ... quando non ricordo come funziona ... e ho ancora meno tempo per fare un cambiamento.

7
Heath Lilley

Provo a scrivere "codice pulito" nel senso di Bob Martin (ad es. OO design). C'è un valore ottimo nella scrittura di codice pulito. È molto più gestibile.

Quindi lascio che ReSharper lo faccia "un bel codice" per me (ad es. Allineamento, interruzioni di riga, ecc.). C'è buono valore nella scrittura del codice grazioso. Ma ci sono rendimenti decrescenti. Alcune preimpostazioni lo rendono un po 'più gestibile a causa della facilità di lettura.

Se ritieni che sia necessario allineare ordinatamente enormi blocchi di codice per renderlo leggibile, allora il problema è che stai impazzendo in un enorme blocco di codice! È troppo grande. Vedo molti esempi di persone che fanno grandi sforzi per imporre un codice progettato molto male.

Se non avessi ReSharper, avrei comunque un codice pulito, ma non sarebbe altrettanto carino.

Non credo che dovrei spendere più del ~ 5% del mio tempo di programmazione in prettificazioni. Il che significa che più potente è il mio editore e più sono abile con esso, maggiore è la prettificazione che posso fare.

5
dss539

Sembra che nessuno sollevi il punto di che cosa è nel migliore interesse della tua azienda?

Spesso, se non sempre, i programmatori sono solo dipendenti, e mentre le decisioni di gestione potrebbero frustrarci, spesso non abbiamo tutti i dati che hanno.

Ad esempio, supponiamo che la società sia contratta con una clausola secondo cui se il software non è pronto in tempo, non verrai pagato (è successo solo a noi, anche se penso che dopo tutto abbiamo ricevuto il pagamento). Sì, il codice pulito è importante, ma più importante è che il codice funzioni entro il giorno del pagamento!

Un altro esempio: la società è in cattiva posizione finanziaria e deve raccogliere fondi. Indovina chi se ne frega della qualità? Puoi ripararlo in seguito, se necessario, spediscilo e basta!

Un argomento potrebbe essere "Perché dovrei esaurire e scrivere codice scadente?". Bene, perché la tua azienda dovrebbe pagarti un assegno Nice ogni mese? Scelte, amico mio. Se cerchi l'idealismo, prova Free Software Foundation ; Ho sentito che stanno facendo delle cose piuttosto interessanti (intendo questo, e rispetto FSF e OSS).

D'altra parte, se lavori su un progetto in cui è prevista una crescita esplosiva nell'uso (sebbene tali proiezioni non siano quasi mai accurate), è meglio gettare delle basi solide con la migliore qualità di codice richiesta, poiché è quasi certo che la manutenzione lo farà essere il costo maggiore per il progetto.

I programmatori adorano il codice "pulito", qualunque cosa significhi. Non possiamo nemmeno essere d'accordo su ciò che è pulito, ma lo adoriamo. Tuttavia, a volte non importa tanto quanto l'usabilità e la correttezza. Questi potrebbero sembrare sinonimi, ma non lo sono - se hai visto il codice scritto da un vero hacker Perl in 4 ore con l'intenzione di essere usato due volte e gettato via, riconosceresti che non è pulito, ma funziona.

Quindi a volte, a parte l'ego, dovremmo semplicemente farlo funzionare. Si noti che non consiglio di scrivere il codice errato come abitudine; Sto solo indicando che potrebbe essere necessario. La perfezione richiede tempo che la tua azienda potrebbe non avere. Quindi, se il tuo datore di lavoro non si preoccupa, crea un software, ma se necessario, scrivi semplicemente il codice di lavoro, non importa la "pulizia". Non è solo una risposta "Taglia unica", devi dare la priorità.

4
K.Steff

Troppo di tutto non è mai buono.

Tuttavia, una cosa importante da tenere a mente con il codice "impuro" è che può facilmente portare a " finestre rotte ". Se il codice è formattato in modo molto scadente, penso che molte persone nuove alla base di codice potrebbero sentirsi meno inclini a fare un buon lavoro con la manutenzione e l'evoluzione, causando una spirale discendente che alla fine potrebbe influenzare le condizioni di lavoro del software.

Pertanto, mantenere un certo livello di pulizia nel codice è vantaggioso per i semplici sviluppatori. Non perdere troppo tempo (è stato menzionato ~ 5%). Impara a usare gli strumenti della tua imbarcazione per automatizzare le attività manuali (formattazione del codice in questo caso). Assumiti la responsabilità di ciò che fai e fai sempre ciò che ritieni più vantaggioso per la tua azienda/clienti/utenti.

3
Per Noalt

Questa è una citazione da Clean Code, di Bob Martin:

Per riportare questo punto a casa, cosa succederebbe se tu fossi un medico e avessi un paziente che ti chiedesse di interrompere tutto lo sciocco lavaggio delle mani in preparazione all'intervento chirurgico perché impiegava troppo tempo? Chiaramente il paziente è il capo; eppure il medico dovrebbe assolutamente rifiutarsi di conformarsi. Perché? Perché il medico conosce più del paziente i rischi di malattia e infezione. Sarebbe poco professionale (non importa criminale) per il medico conformarsi al paziente.

Quindi anche per i programmatori non è professionale piegarsi alla volontà dei manager che non comprendono i rischi di fare casini.

3
Tulains Córdova

Non sono sicuro che "avere un bell'aspetto" ed essere "elegante, perfettamente comprensibile e mantenibile" sia equivalente.

Cerco di scrivere codice, che sia "elegante, perfettamente comprensibile e mantenibile". Rifattorizzo il mio codice per adattarlo meglio a tali criteri.

Non vedo alcun inconveniente, tranne il costo risultante nel tempo.

Affinché il codice "abbia un bell'aspetto", ci sono molti strumenti automatizzati che indentano e spaziano correttamente tutto ciò che desideri.

3
back2dos

Mi piace che il codice sia leggibile, ma la cosa più importante è la coerenza. Per me ciò significa coerenza con le convenzioni di denominazione e spaziatura tra funzioni, parentesi sulla stessa riga o sulla riga successiva dell'istruzione if, ecc.

Certo, ci sono momenti in cui qualcuno programma qualcosa con uno stile di codice coerente e mi fa ancora impazzire. Soprattutto codice che non "respira". Per esempio:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Bene ... Sembra peggiore con i metodi Objective-C e con un sacco di istruzioni if ​​annidate e righe molto più lunghe di 80 caratteri. Ma mi infastidisce ancora :)

2
vedosity

Penso che il "codice pulito" dovrebbe essere altrettanto pulito o più pulito di come si scriveva negli esami di fisica/ingegneria/matematica. Se è troppo disordinato, il selezionatore non capirà il tuo lavoro e probabilmente lo segnerà come sbagliato anche se è giusto.

2
chiurox

Vado molto a pulire il codice. Penso che aiuti enormemente i bug a risaltare.

Non sono d'accordo con il concetto di "spedisci la fottuta cosa adesso", perché il codice pulito è un investimento per il futuro. Anche troppi software vengono spediti con troppi bug. Risolvere un bug secondo me è meglio che implementare una nuova funzionalità.

Inoltre, se guardi stime della produttività del programmatore , non credo di avere un punteggio molto basso. Scrivere codice pulito è un'abitudine, e più esperienza come programmatore, tanto più si diventa efficienti. Se uno non lo prova mai, ovviamente, non lo farà mai esperienza.

Un altro punto da tenere in considerazione è che la maggior parte del tempo degli sviluppatori passa alla lettura del codice, quindi il codice leggibile riduce notevolmente i tempi di lettura. Comprendere algoritmi non documentati, ad esempio, può essere costoso e invitare nuovi bug.

Una cosa che sicuramente mi manca e mi piacerebbe avere un giorno è un formattatore di codice automatico che potrei adattare al mio stile, il che mi farebbe risparmiare un po 'di tempo, specialmente quando leggo il codice di altre persone.

La codifica pulita ha un legame con il perfezionismo, che ha il rischio di non materializzarsi mai, ma penso che sia principalmente un problema quando inizi, perché investi più tardi e quando riutilizzi i tuoi eleganti pezzi di codice, combinati con la tua esperienza invecchiando sarai molto produttivo e molto meno infestato dai bug rispetto ai programmatori disordinati.

Questo è un pezzo di codice che dimostra il mio stile di codifica.

2
user20416

Evita semplicemente il "codice vanità". Ci sono molti sviluppatori là fuori che fanno cose puramente per vanità (o a causa di un disturbo ossessivo compulsivo) e nient'altro. Le mie mutandine sono davvero contorte con quelle persone.

1
ElGringoGrande

Scrivo codice che tenta di risolvere il problema dato nel modo più efficiente e teoricamente "elegante". In quel senso solo è pulito. Se capita di essere "carino" quando ho finito, così sia.

Quello che ho scoperto nelle mie esperienze limitate è che quando le persone si lamentano del "codice pulito", la bruttezza è di solito il risultato di una soluzione terribile piuttosto che di una convenzione di codifica.

1
Kurtis

Direi che faccio uno sforzo per scrivere un codice più pulito, ma ciò può cambiare a causa di vincoli di tempo o se sto lavorando a qualcosa di difficile. Tende a diventare disordinato quando ci si concentra sul farlo funzionare. Poi torno indietro e pulisco mentre lo recensisco. Se ritorni al codice e devi dedicare troppo tempo ad aggiornare la tua memoria, non hai commentato abbastanza.

Il codice pulito è buono ma come tutto il resto, deve solo essere abbastanza pulito. Il rientro di 5 righe di codice 4 spazi e di una riga 5 spazi non aumenta la difficoltà di lettura.

1
JeffO

Penso che dipenda da cosa stai facendo. Se sto scrivendo un'applicazione di prova di concetto, in pratica sto codificando il culo da cowboy e non guardo indietro. Se sto lavorando su un'applicazione su cui lavorerò per un po ', allora mi assicuro di codificarlo abbastanza bene e renderlo comprensibile tra un mese.

Penso che lo stile del tuo codice sia un po 'incerto. Come alcuni hanno già detto, il tuo compito è quello di creare un prodotto, non un codice formattato, ma direi almeno che uno dovrebbe attenersi a uno stile definito di commentare e scrivere codice. Odierei vedere metà delle variabili camel racchiuse e l'altra metà ungherese.

Ma dipende anche da cosa intendi per "codice pulito".

1
user7007

Rifattorizzare il codice per renderlo elegante rende più facile la lettura e la manutenzione. Anche cose minori come l'allineamento delle assegnazioni delle variabili:

int foo    = 1;
int bar    = 2;
int foobar = 3;

è più facile da leggere di

int foo = 1;
int bar = 2;
int foobar = 3;

il che significa che è più facile ignorare quando esegui il debug in seguito.

Inoltre, in PHP è consentito qualsiasi numero di blocchi di codice casuali. Li uso per raggruppare attività logiche:

// do x
{
    // ...
}

// do y
{
    // ...
}

Ciò aggiunge una definizione chiara al codice pertinente.

Modifica: come bonus aggiuntivo, è facile precedere uno di quei blocchi di codice logici con un if (false) se vuoi saltarlo temporaneamente.

0
Craige

Ammetto di farlo; e il vantaggio non si infastidisce ogni volta che lo vedo. Immagino sia anche più facile da leggere, e quindi i bug diventano più evidenti; ma la vera ragione è che non sopporto il codice brutto.

0
user281377