Scrivi effettivamente "codice pulito"? [chiuso]

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

Mi viene in mente il post del blog di Joel Spolsky: Il programmatore di nastro adesivo condotto .

Cita da Coders at Work :

At the end of the day, ship the f*****g thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products. - Jamie Zawinsky

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

So. Be smart. Be clean. Be simple. Ship! And keep a small roll of duct tape at the ready, and don’t be afraid to use it. - Uncle Bob

Se il codice, uno sviluppatore scrive che è pulito E lavora (è consegnabile), così sia, buono per tutti. Ma se uno sviluppatore sta cercando di creare codice pulito e leggibile a scapito di poterlo consegnare tempestivamente, allora è male. Fallo funzionare, usa del nastro adesivo e spediscilo. Puoi refactoring in seguito e renderlo super splendido ed efficiente.

Sì, è buona norma scrivere codice pulito, ma mai a spese di essere in grado di fornire. Il vantaggio di consegnare in tempo utile un prodotto con nastro adesivo supera di gran lunga i vantaggi del codice pulito che non è mai stato completato e consegnato.

Un buon pezzo di codice che ho trovato 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 è consegnare il codice che funziona, che sia pulito o disordinato. Lo sviluppatore deve fare il meglio che può, dato il tempo che è stato assegnato prima della consegna. Quindi, torna a ripulire: è professionale. Si spera che il codice consegnato non sia puro nastro adesivo e sia "abbastanza pulito".

Devi assicurarti che il tuo codice sia molto leggibile, pulito e manutenibile. Questo è ciò che tutti i programmatori devono fare.

Ma stai parlando di over styling (come quel termine meglio di codice ragazza ) che non serve nient'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 che gli spazi bianchi corretti tra i membri fossero rispettati.

È troppo.

Trovo che quel tipo di comportamento sia controproducente. In un contesto professionale , devi essere professionale . Puoi ottenere la tua soddisfazione scrivendo 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 di spedizione, ma di solito hai anche la responsabilità di spedire qualcosa che sia manutenibile il più economicamente possibile da te stesso e dai futuri sviluppatori.

Ho trascorso periodi come quel povero programmatore o consulente di manutenzione sul posto che deve capire e fare il debug di un enorme sistema non documentato, e posso dirti che disegni scadenti e codice confuso e disordinato possono portare a ore o addirittura a giorni di sforzi inutili . Posso pensare a molte situazioni in cui un ulteriore sforzo di N ore da parte dello sviluppatore iniziale potrebbe portare a un risparmio sui costi di 5 N in termini di tempo.

So che c'è una statistica che fluttua intorno 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 ripulire il codice entro un centimetro della sua vita . Ci vuole tempo, ma è probabilmente un risparmio netto per tutta la vita del progetto.

Qualcuno di noi comprerebbe una macchina se sappiamo che sotto la cappa è tutto complicato e difficile da risolvere, mantenere o correggere e ci vuole più risorse per l'esecuzione 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 verrà mostrato.

Rispondere alla domanda "In realtà scrivi 'codice pulito'?" - Oh, Sì.!

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

Heck yes.

Più pulito, più chiaro è il codice, più semplice è il mantenimento, e quindi risparmiare tempo a lungo termine. Non guardare il codice pulito come vanità; guardalo come un investimento per risparmiare sforzi e tempo futuri.

Onestamente dipende. Mi piace il modo in cui tutti parlano del modo in cui "qualcosa di meno di un codice ben documentato pulito è una pura traversata!", Ma lavoro in un business con ridicoli cicli di implementazione e supervisione zero: faccio il meglio che posso, ma scrivo così molto codice è estremamente difficile scrivere il codice perfetto e pulito che tutti gli altri rivendicano scrivono.

Cerco di scrivere codice che possa essere facilmente mantenuto da qualcuno che ha più o meno le mie capacità. Io commento le parti difficili, chiamo i programmi, le variabili e le classi, i nomi amichevoli, io dispiego, e io proseguo. Non ho tempo per fare altro.

A volte mi sento un po 'in colpa, ma non molto. Dovresti vedere alcuni degli orrori con cui mi occupo quotidianamente. Decenni di codice personalizzato in lingue oscure con documentazione zero. Uno dei miei collaboratori si sviluppa esclusivamente in Visual Basic 6.0 e distribuisce in modo discriptico i binari denominati in ogni punto. La donna che ho sostituito programmata esclusivamente in RPG .

È estremamente difficile per me credere, sia una stronzata orribile che ho visto nei miei anni da programmatore, che tutti genera solo codice pulito.

Non penso che mi piaccia il termine "codice ragazza" ma codice pulito = codice gestibile. Qualunque cosa in meno non è professionale.

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

Molto spesso sono io ... diversi mesi dopo ... quando non ricordo come funziona ... e ho ancora meno tempo per cambiare.

Cerco di scrivere "codice pulito" nel senso di Bob Martin (ad esempio, progettazione OO). C'è un grande valore nella scrittura di codice pulito. È molto più gestibile.

Quindi ho lasciato che ReSharper rendesse "pretty code" per me (ad esempio allineamento, interruzioni di linea, ecc.). C'è un valore buono nella scrittura di un bel codice. Ma ci sono rendimenti decrescenti. Qualche prettificazione lo rende un po 'più gestibile grazie alla facilità di lettura.

Se ritieni che allineare ordinatamente enormi blocchi di codice sia necessario per renderlo leggibile, allora il problema è il tuo enorme blocco di codice! È troppo grande. Vedo molti esempi di persone che si prendono molta cura di progettare un codice molto mal progettato.

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

Non penso che dovrei spendere più del ~ 5% dei miei tempi di codifica in fase di preparazione. Il che significa che più potente è il mio editore e più abile con esso, più è la cosa che posso fare.

Sembra che nessuno sollevi il punto di cosa c'è nell'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 fanno.

Ad esempio, supponiamo che la società abbia una clausola contrattuale che se il software non è pronto in tempo, non verrai pagato (ci è appena successo, anche se penso che abbiamo ricevuto il pagamento dopo tutto). Sì, il codice pulito è importante, ma più importante è far funzionare il codice entro il giorno di pagamento!

Un altro esempio: la compagnia è in cattive condizioni finanziarie e ha bisogno di raccogliere denaro. Indovina chi se ne importa della qualità? Puoi aggiustarlo più tardi, se necessario, spediscilo!

Un argomento potrebbe essere "Perché dovrei vendere e scrivere codice scadente?". Bene, perché la tua azienda dovrebbe pagarti un bel controllo ogni mese? Scelte, amico mio. Se sei alla ricerca di idealismo, prova la Free Software Foundation ; Ho sentito che stanno facendo cose interessanti (intendo questo, e rispetto FSF e OSS).

Dall'altro lato, se si lavora a un progetto in cui è prevista una crescita esplosiva nell'uso (anche se tali proiezioni non sono quasi mai accurate), è meglio gettare alcune solide fondamenta con la migliore qualità del codice richiesta, poiché è quasi una certa manutenzione sarà il costo maggiore per il progetto.

I programmatori amano 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'intento di essere usato due volte e gettato via, riconoscerai che non è pulito, ma funziona.

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

Non sono sicuro che "stia bene" ed essere "elegante, perfettamente comprensibile e mantenibile" è equivalente.

Cerco di scrivere codice, cioè "elegante, perfettamente comprensibile e gestibile". Rifoco il mio codice per abbinare meglio questi criteri.

Non vedo alcun inconveniente, tranne il conseguente costo in termini di tempo.

Affinché il codice "sembri buono", ci sono molti strumenti automatici, che indentano e spaziano correttamente tutto come desideri.

Troppo di tutto ciò non è mai buono.

Tuttavia, una cosa importante da tenere a mente con il codice "non pulito" è che può facilmente portare a " finestre rotte ". Se il codice è formattato molto male, 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 potrebbe eventualmente influire sulle condizioni di lavoro del software.

Quindi mantenere un certo livello di pulizia nel codice è vantaggioso per qualcosa di più dei tuoi colleghi sviluppatori. Non spendere troppo tempo su di esso (~ 5% è stato menzionato). Impara a usare gli strumenti del tuo mestiere 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 / i clienti / gli utenti.

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

To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.

So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.

Penso che "codice pulito" dovrebbe essere più pulito o più pulito di come si scriveva durante gli esami di fisica / ingegneria / matematica. Se è troppo disordinato, il selezionatore non capirà il tuo lavoro e probabilmente lo segnerà male 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 le funzioni, parentesi sulla stessa riga o la 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 il codice che non "respira". Ad 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 nidificate if e linee molto più lunghe di 80 caratteri. Ma mi infastidisce ancora:)

Vado molto bene a pulire il codice. Penso che sia di grande aiuto per gli errori.

Non sono d'accordo con il concetto "spedisci la fottuta ora", 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à.

Anche se guardi stime della produttività del programmatore , non penso di avere un punteggio molto negativo. Scrivere codice pulito è un'abitudine e più esperienza come programmatore, più efficiente diventa. Se non ci provi mai, ovviamente, non ne avrai mai esperienza.

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

Una cosa che sicuramente mi manca e vorrei che un giorno sia un formattatore di codice automatico che potrei adattare al mio stile, che mi farebbe davvero risparmiare tempo, specialmente leggendo il codice di altre persone.

La codifica pulita ha un legame con il perfezionismo, che rischia di non materializzarsi mai, ma penso che sia principalmente un problema quando inizi, perché investi in seguito e riutilizzando 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.

Evita semplicemente il "codice vanity". Ci sono molti sviluppatori là fuori che fanno cose puramente per vanità (o per colpa di un OCD) e nient'altro. Le mie mutandine si intrecciano davvero con quelle persone.

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

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

Direi che mi sforzo di scrivere codice più pulito, ma che può cambiare a causa di vincoli di tempo o se sto lavorando su qualcosa di difficile. Tende a diventare disordinato quando si concentra sul farlo funzionare. Poi tornerò indietro e ripulirò mentre lo rivedo. Se torni al codice e devi trascorrere troppo tempo ad aggiornare la tua memoria, non l'hai commentato abbastanza.

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

Penso che dipenda da ciò che stai facendo. Se sto scrivendo un'applicazione di proof-of-concept, in pratica sto praticamente codificando da cowboy e non guardandomi indietro. Se sto lavorando a un'applicazione su cui lavorerò per un po ', allora mi assicurerò di codificarla abbastanza bene e renderla comprensibile tra un mese.

Penso che stilare il tuo codice sia un po 'incerto. Come alcuni hanno già detto, il tuo compito è quello di creare un codice prodotto, non formattato, ma direi che almeno uno dovrebbe attenersi a uno stile definito di commenti e codifica. Mi dispiacerebbe vedere la metà delle variabili cammello e l'altra metà ungherese.

Ma dipende anche da cosa intendi con 'clean-code'.

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

Rifacendo il codice per renderlo elegante, è più facile da leggere e più facile da mantenere. Anche cose minori come allineare le 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;

che significa che è più facile scavalcare quando esegui il debug in un secondo momento.

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

// do x
{
    // ...
}

// do y
{
    // ...
}

Questo aggiunge una definizione chiara al codice pertinente.

Modifica : Come bonus aggiuntivo, è facile precedere uno di quei blocchi logici di codice con if (false) se si desidera saltarlo temporaneamente.

Scrivo solo il mio codice, seguendo gli standard aziendali. Se lo voglio "a prua", posso farlo tramite un beautifier del codice.