Scrivi davvero 'codice pulito'? [chiuso]

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 veramente 'codice pulito'? È una buona pratica? Quali sono gli altri vantaggi o svantaggi di questo?

Direi che molti di noi non scrivono codice pulito . E generalmente 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 in mente 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 un prodotto registrato in modo puntuale 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".

Devi assicurarti che il tuo codice sia molto leggibile, pulito e gestibile. Ecco cosa devono fare tutti i programmatori .

Ma stai parlando over styling(come quel termine meglio di quel codice-ragazza ) 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 trascorso 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 professionale . Puoi ottenere la tua soddisfazione scrivendo un codice pulito, molto leggibile e gestibile e parlando con utenti o colleghi felici.

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 scritta viene letta 5-20 volte durante l'estensione e la manutenzione.

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

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.!

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

Cavolo si.

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à; consideralo un investimento per risparmiare tempo e sforzi futuri.

Onestamente dipende. Mi piace il modo in cui tutti esprimono la linea del partito su come "niente di meno che un codice pulito e ben documentato sia 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 affermano di scrivere.

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 GdR .

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

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.

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

Poi ho lasciato che ReSharper lo rendesse "un bel codice" per me (ad es. Allineamento, interruzioni di riga, ecc.). C'è un buon valore nello scrivere un bel codice. 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, più posso fare.

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

Spesso, se non sempre, i programmatori sono solo dipendenti e, sebbene le decisioni di gestione possano frustrarci, spesso non disponiamo di tutti i dati che possiedono.

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 buon assegno ogni mese? Scelte, amico mio. Se cerchi l'idealismo, prova la Free Software Foundation ; Ho sentito che stanno facendo 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 al tuo datore di lavoro non importa, crea un software, ma se è necessario, basta scrivere un codice funzionante, non importa la "pulizia". Non è solo una risposta "Taglia unica", devi dare la priorità.

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.

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.

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

Per riportare questo punto a casa, cosa succederebbe se tu fossi un dottore 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.

Penso che il "codice pulito" dovrebbe essere altrettanto pulito o più pulito di come scrivevi 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.

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 :)

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 si guardano le 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 programmazione.

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.

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.

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.

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 ad 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".

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.

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 compiti logici:

// 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 si desidera saltarlo temporaneamente.

Scrivo solo il mio codice, seguendo gli standard dell'azienda. Se lo voglio "pronto", posso eseguirlo tramite un beautifier di codice.