Non fraintendermi. Non voglio che tu ti senta male. Avevo questi segnali, e ho lavorato duramente per migliorarmi. Se non conosci i tuoi difetti, come puoi rimediare? Abbiamo bisogno di qualcuno che ci dica queste cose, ma la maggior parte dei programmatori non ha quel qualcuno.

La maggior parte delle volte sappiamo cosa dovremmo fare, ma non lo facciamo. Pensiamo di poterlo fare in seguito o correggerlo in seguito. Ma il “dopo” non arriva mai. Questo è un segno comune di un programmatore pigro e il primo passo per essere un cattivo programmatore.

Ieri ho letto un meraviglioso lungo articolo di Daryll Santos da GitHub. Ho riassunto e selezionato alcuni dei segni che mi sembravano rilevanti. Allora entriamo nei fatti.

Non capisco l'obiettivo del codice

Prima di scrivere il codice, devi conoscere gli scopi del codice, cosa farà il tuo codice. È come eseguire il codice nella tua testa.

Sintomi

1. Mantenere le variabili che non vengono mai utilizzate.
2. Produrre un output irrilevante.
3. Chiamare funzioni irrilevanti per l'obiettivo.
4. Esecuzione di funzioni idempotenti, come save() più volte, per sicurezza.
5. Risolvere i bug scrivendo alcuni codici che sovrascrivono il codice buggato.
6. Conversione di valore non necessaria. Come prima convertire un decimale in una stringa e poi convertire di nuovo la stringa in decimale.

1. Usa il debugger dell'IDE come aiuto.
2. Ispezionare il valore delle variabili prima e dopo la modifica.

La programmazione orientata agli oggetti è un modello di programmazione, così come la programmazione funzionale o dichiarativa. Sono diversi dalla programmazione procedurale o dichiarativa. I programmatori si sono confusi quando sono passati da un'architettura all'altra, ed è normale. Ma con il tempo, devi avere una migliore comprensione di quell'architettura.

Sintomi

1. Non segue lo standard OOP.
2. (OOP) Chiamare funzioni/variabili non statiche in classi non istanziate.
3. (OOP) Scrivere molte classi "XXXXManager" con tutti i metodi per manipolare i campi degli oggetti con un metodo piccolo o nessun metodo proprio.
4. Trattare un database relazionale come un archivio di oggetti.
5. Esecuzione di tutti i join e l'imposizione di relazioni nel codice client.
6. Creazione di più versioni dello stesso algoritmo per gestire tipi diversi.
7. Impostazione di valori individuali (in codici imperativi) anziché utilizzare l'associazione dati.

1. Questo non è qualcosa che puoi superare in un giorno. Devi esercitarti, esercitarti e ancora esercitarti.
2. Lettura della documentazione. Se non capisci l'architettura del linguaggio o le basi OOP, investi tempo per capire meglio.
3. Segui il codice del programmatore senior.

Quando la tua logica è povera, avrai confusione e diffiderai dei tuoi stessi codici.

Sintomi

1. Scrivere IsNull() o IsNotNull() o IsTrue(bool) o IsFalse(bool) funziona inutilmente.
2. Verificare se una variabile di tipo booleano è qualcosa di diverso da vero o falso.
3. Chiamare le stesse funzioni più volte per confermare l'esecuzione.

1. Non portare vecchie abitudini inutili da una lingua con un sistema di tipo debole.
2. Sii sicuro della tua logica. Se ci sono problemi con la logica, prova una nuova logica.

L'idea della ricorsione è complicata ma non così difficile. Ma molti programmatori temono la ricorsione come i fantasmi. La ricorsione renderà il codice più pulito ed efficiente. La ricorsione è come una scala. devi solo immaginare "dove sei" e "dov'è la base" e come salirai o scenderai.

Sintomi

1. Algoritmi iterativi complessi per problemi che possono essere risolti ricorsivamente. Come attraversare un albero di filesystem.
2. Verifica delle condizioni di base sia prima che dopo la chiamata ricorsiva.
3. Funzioni ricorsive che non verificano una condizione di base.
4. Subroutine ricorsive che concatenano/sommano a una variabile globale oa una variabile di output carry-along.

1. Eseguire il codice in più passaggi per comprendere il flusso. Potrebbero verificarsi alcuni overflow dello stack. Ma non preoccuparti.
2. Modificare la condizione di base per vedere gli output.
3. Il tuo obiettivo è avere fiducia e un senso completo di dove sei e cosa stai facendo.

I framework e i linguaggi moderni hanno una straordinaria ampiezza e profondità di comandi e funzionalità integrati. La conoscenza è così grande che un buon programmatore avrà bisogno di più di qualche anno per consumarla. Ma un buon programmatore cerca sempre una funzione incorporata prima di iniziare a scaricarne una propria.

Sintomi

1. Reinventare senza meccanismi di base incorporati nel linguaggio, come eventi e gestori o espressioni regolari.
2. Reinventare classi e funzioni integrate nel framework.
3. Piuttosto che cercare, "Inviami il codice via e-mail, per favore" messaggi pubblicati per aiutare i forum da loro.
4. Utilizzo persistente di tecniche antiquate anche quando le nuove tecniche sono migliori in quelle situazioni.
5. Piuttosto che cercare una soluzione semplice, rendila complessa scrivendo "Codice della rotonda" che realizza ciò che potrebbe essere fatto con meno codici in molti passaggi.

1. Questa abilità richiede tempo per essere costruita. Quindi non avere fretta.
2. Non andare da un programmatore o copiare e incollare direttamente il codice quando sei bloccato in un problema. Prendere tempo. Leggi la documentazione.

Se non capisci il concetto di puntatori, sarà molto difficile per te scrivere strutture dati complesse e API efficienti. Genererai un design scadente della struttura dei dati e bug.

Sintomi

1. Mancanza di conoscenze per distinguere tra pass-by-value e pass-by-reference nelle chiamate di metodo.
2. Mancata implementazione di elenchi collegati.
3. L'impossibilità di trovare o correggere i bug si è verificata eseguendo erroneamente l'aritmetica sui puntatori.
4. Incapacità di scrivere codice che inserisca/elimina nodi da un elenco collegato o da un albero senza perdere o eliminare i dati.
5. Fare una copia di un puntatore, modificare il valore dereferenziato tramite la copia, quindi pensare che il puntatore originale punti ancora al vecchio valore.

1. Il puntatore è molto facile da capire ma spesso viene frainteso a causa della mancanza di pratica.