10 modi per scrivere codice di merda
giovedì 4 giugno 2009
(5 voti, media: 5,00)
Loading ...Per la serie 10 modi di... Ecco il non plus ultra della programmazione.
Seguite questa piccola guida e vedrete che il vostro codice diventerà l'incubo di ogni vostro collega!
- Non commentate
I commenti sono inutili. E portano via un sacco di spazio. JavaDoc? PhpDoc? E chi ve lo fa fare? Perdete solo tempo! - Non prototipizzate
Partite con lo scrivere codice. Chi vivrà vedrà: al massimo si cambia il database in corsa, che sarà mai! - Non indentate
Cicli su una riga sola? Blocchi di codice che cominciano tutti alla colonna zero? Viva!
- $pippo è tua amica
Più scrivete cripticamente il vostro codice meglio è. Nomi di variabili come i, j, k, var1, var2, ecc... Bastano e avanzano. Perché perdere tempo a dare un nome coerente alle cose? - MVC? Design Patterns? Che roba è?
Codice su codice, dentro template, dentro pagine html, dentro file di testo, dentro matrioske. Alla fine seguire il flusso è anche divertente - Tutto in una cartella!
Mettere tutto il vostro codice in una sola cartella è un toccasana per il vostro filesystem, non dimenticatelo! - Chiavette USB a gogo
Condividere progetti con il vostro collega via chiavette USB è santa cosa. Con i prezzacci di oggi vi portate a casa 8GB di chiavetta ad una manciata di euro. SVN? CVS? Source Safe? Lasciate perdere - if else if else if , what?:
Annidare gli if e aggiungere condizioni alla bisogna è l'unico modo veloce per fare le cose. - Non programmate ad oggetti
E' tutta una gran palla questa della OOP. Che male c'è ad usare decine di funzioni tutte uguali (tranne che per qualche riga)? E perchè poi dovrei perdermi tra classi, attributi, metodi, ecc...? - Testing? Neanche morto!
Perché testare il codice prima del rilascio? Tanto al massimo le modifiche le fatturo a parte in caso di problemi.
Piaciuta la guida? Ecco, adesso prendetela, stampatela, mettetela accanto alla vostra scrivania e fate esattamente il contrario.
Questo articolo è stato pubblicato giovedì, 4 giugno 2009 alle ore 07:41
Se non vuoi perdere nemmeno un articolo del mio blog abbonati al feed RSS. Se non sai cos'è un feed RSS puoi guardare questo video, spiega tutto!
In alternativa puoi abbonarti alla newsletter, riceverai un'email ogni volta che verrà pubblicato un nuovo post. Il tuo indirizzo email sarà gestito da Feedburner.
4 giugno 2009 alle 07:49
Ma.. come? Al contrario?!?! Sul serio?? Ma da me i veri programmatori, quelli che si ritengono con i controcazzi e che ogni ogni volta che parli loro cercano di farti sentire un’essere abominevole ed inutile (in quanto donna), seguono il decalogo alla perfezione!!
‘Spetta me che lo stampo in 20 copie e oggi lo distribuisco!!
4 giugno 2009 alle 08:18
Mi ricorda il css che ha scritto un mio collega e che io ho dovuto modificare, per la serie header.q, header.s, header.f non ti dico cosa gli ho detto quando ho finito
4 giugno 2009 alle 08:35
Hai vinto tu… sto ancora ridendo!
Ho stampato il post e messo sulla scrivania di almeno 3 miei colleghi!
hi h ihi
4 giugno 2009 alle 09:24
hahaha questo deve fare il giro del mondo
parto ora con i programmatori svizzeri 
4 giugno 2009 alle 09:57
Waitaminute… nel punto 10 non ci vedo nulla di male
si chiama Capitalismo.
4 giugno 2009 alle 13:13
@ tillo:
LOL! Temo però che un eventuale cliente possa non essere d’accordo
4 giugno 2009 alle 13:54
Non le ho mai incontrate tutte e dieci insieme ma non conosco neppure un programmatore che non ne applichi sistematicamente almeno una (compreso il sottoscritto
)
5 giugno 2009 alle 01:31
Ah ah ah … bella questa!
Io studio ingegneria informatica e di ste cose ne vedo parecchie.
Soprattutto sui commenti, astrazione del codice, indentazione, variabili con nomi incomprensibili, ecc.
E se cerchi di correggerli ti criticano anche!
Frase esempio: “sbrigati!. ma che cavolo fai?! cosa sono i ‘//’ ”
5 giugno 2009 alle 09:32
E’ come sparare sulla croce rossa! Ora però che hai reso pubblico l’indice puoi iniziare a scrivere i capitoli in modo più approfondito per far capire bene a chi sta là fuori cosa non si deve fare, che strumenti è utile usare…insomma cercare di far tornare qualcuno sulla retta via. E non sto scherzando.
Proprio pochi giorni fa ho pubblicato un post riguardante SVN e l’impatto che può avere specialmente nei piccoli team dove in molti (aziende) pensano che strumenti del genere non siano utili.
Purtroppo alcune delle cose che indichi possono essere “imposte” dall’ambiente in cui ti trovi (niente strumenti di versioning, nessun coding standard, no OP), cercare di migliorare le cose però deve essere sentito come una sfida da chi cerca di fare le cose bene. E farlo è per il proprio bene e per la qualità dei progetti che si realizzano.
6 giugno 2009 alle 17:58
Penso che ne distribuisco un po’ di copie all’università
Purtroppo capita spesso di trovare colleghi che lavorano così…