[GENERALE] Regole di buona programmazione

[Tadde]

Invece di discutere di quale linguaggio sia "migliore", o di usare un forum di discussione come un help-desk, mi piacerebbe discutere con voi di buone pratiche di programmazione, regole cioè che prescindono dalla sintassi del linguaggio particolare.

Ad esempio buone o consigliate convenzioni nei nomi di metodi (o funzioni) e variabili (o campi); accorgimenti per rendere il codice più facilmente leggibile e manutenibile, tipo inizializzare SEMPRE le variabili; se usare o meno condizioni booleane complicate nei blocchi decisionali (diminuendone il numero) contro condizioni booleane elementari ma che costringano chi legge a seguire più ramificazioni; poi supponiamo che una delle ramificazioni di un if... else sia molto più corta dell'altra, allora ho notato che è più scorrevole la lettura se la condizione dell'if è tale da permettere al programmatore di scrivere tale breve blocco PRIMA di quello molto più lungo (in questo modo chi legge "si toglie subito il dubbio" di dove va a parare il flusso del programma se quella condizione viene verificata e può proseguire la lettura) ecc...

Insomma sono sicuro che molti dei programmatori più esperti che bazzicano questo forum ne hanno di accorgimenti e consigli da dare, anche prescindendo dal linguaggio, quindi fatevi avanti

[shinya]

Originariamente inviato da Tadde

Insomma sono sicuro che molti dei programmatori più esperti che bazzicano questo forum ne hanno di accorgimenti e consigli da dare, anche prescindendo dal linguaggio, quindi fatevi avanti

Non credo si possa prescindere dal linguaggio più di tanto. Non puoi "inizializzare SEMPRE le variabili" se le variabili non esistono; i "design pattern" classici non aiutano molto se programmi in lisp. Giusto per fare due esempi.

Comunque, alcune risorse che ritengo ottime, e che contengono anche (forse poche) indicazioni di carattere generale:
Factor Philosophy
Effective Java
Google C++ Style Guide

[ndakota]

anche questo link è ottimo http://sourcemaking.com/

[PGI-Bis]

La prima regola della buona programmazione è finire il programma.

[DanieleC88]

Originariamente inviato da ndakota

anche questo link è ottimo http://sourcemaking.com/

Simpatico il link! Ctrl+D.

[shinya]

Originariamente inviato da PGI-Bis

La prima regola della buona programmazione è finire il programma.

Mai visto un programma finito.
A meno che per 'finito' non intendiamo 'fatturato' e/o 'che nessuno utilizza'.

[ndakota]

Originariamente inviato da shinya

Mai visto un programma finito.
A meno che per 'finito' non intendiamo 'fatturato' e/o 'che nessuno utilizza'.

O a meno che per 'finito' non si intenda che ci si è messa una pietra sopra

[PGI-Bis]

Originariamente inviato da shinya

Mai visto un programma finito.
A meno che per 'finito' non intendiamo 'fatturato' e/o 'che nessuno utilizza'.

Il programma è finito quando lo dai a quello che te l'ha chiesto - e dovrebbe pagartelo - e quello non ti richiama per dirti "ma che cacchio, non funziona".

[recoil]

Originariamente inviato da Tadde

Insomma sono sicuro che molti dei programmatori più esperti che bazzicano questo forum ne hanno di accorgimenti e consigli da dare, anche prescindendo dal linguaggio, quindi fatevi avanti

la maggior parte dei progetti in cui ho lavorato ha riguardato manutenzione di codice o aggiunta di feature a progetti già esistenti, quindi ho tentato il più possibile di mantenere lo stile originale

secondo me è necessario innanzitutto commentare le funzioni specificando in due righe qual è lo scopo della funzione/metodo e dando una descrizione dei parametri di ingresso e dell'uscita.
ci sono delle convenzioni per generare automaticamente della documentazione a partire dai commenti (tipo il Javadoc ma c'è anche per altri linguaggi) quindi è un'ottima cosa per avere già quasi fatto pure il documento di specifiche funzionali

qualche commento va messo anche nel codice, magari evitando i commenti "ovvi". è bene inserire una breve spiegazione quando si fa un'operazione che non è chiara alla prima occhiata.

altra cosa è il nome delle variabili. per il classico contatore del ciclo for va bene usare i/k/n mentre per le altre è meglio usare nomi che in qualche modo ne descrivano il significato, almeno è subito chiaro cosa si sta facendo quando si manipola quella variabile.

spezzare il codice in diverse funzioni o usare più classi è un altro modo per rendere più chiaro il listato.
di recente ho dovuto lavorare su un progetto dove c'era un file di 20.000 righe con circa un centinaio di funzioni, è la cosa migliore per creare confusione e tirar scemo chi deve metterci mano dopo... ovviamente zero commenti.

in generale la buona regola che uso è tentare di rendere il codice leggibile. a distanza di mesi pure quello che abbiamo scritto noi stessi può rivelarsi ostico senza commenti e con nomi alla cazzo, figuriamoci cosa può capirne un estraneo!
ecco perché evito pure il codice troppo "compatto" facendo ad esempio delle mega if con dentro di tutto e di più. preferisco avere un listato più lungo, ma meno "largo" e fatto di operazioni tutto sommato semplici


naturalmente questo è il modo in cui lavoro io, ciascuno ha la propria esperienza e metodo di lavoro.

[banryu79]

Originariamente inviato da recoil

di recente ho dovuto lavorare su un progetto dove c'era un file di 20.000 righe con circa un centinaio di funzioni, è la cosa migliore per creare confusione e tirar scemo chi deve metterci mano dopo... ovviamente zero commenti.

Quelle 20.000 righe "impaccate" in un unico file probabilmente a livello concettuale erano rappresentabili in 1 o più package, formati da almeno un 15 20 classi. Ma proprio minimo.

Lavorare su roba del genere deve essere un incubo. (Poi dipende anche dalla cura con cui è scritto quel codice, ma se queste sono le premesse lascia intendere il peggio)

[yorkeiser]

Butto la mia su quello che NON si dovrebbe fare: recentemente, a causa di modifiche legislative in ambito assicurativo, ho dovuto mettere mano a un accrocchio (una serie di programmoni) VB6 ( ) che si preoccupano di rinnovare in automatico le polizze dei clienti. Ebbene, io non avevo mai visto una funzione di 1800 righe di codice composta esclusivamente da if annidati fino al 14° livello (li ho contati) e con indentazione assolutamente casuale. Per inciso, l'IDE VB6 non ha strumenti di indentazione automatica.
Da qui due regoline: in primis, indentare il codice.
In secundis: imparare a strutturare i dati in maniera furba e soprattutto riutilizzabile, pensando sempre al fatto che prima o poi qualcun'altro metterà le mani sul tuo lavoro. E cercare di non utilizzare variabili globali, nel caso il linguaggio lo permetta.

[banryu79]

Originariamente inviato da yorkeiser

Ebbene, io non avevo mai visto una funzione di 1800 righe di codice composta esclusivamente da if annidati fino al 14° livello (li ho contati) e con indentazione assolutamente casuale.

E meno male che lo chiamano software... roba del genere è inamovibile e immodificabile per il semplice fatto che è inguardabile
Non ho mai avuto il dispiacere di avere a che fare con codice altrui scritto così tanto male; però penso che come esperienza, farla almeno una volta, sia molto formativa, anche se dolorosa...

[khelidan1980]

Originariamente inviato da banryu79

E meno male che lo chiamano software... roba del genere è inamovibile e immodificabile per il semplice fatto che è inguardabile
Non ho mai avuto il dispiacere di avere a che fare con codice altrui scritto così tanto male; però penso che come esperienza, farla almeno una volta, sia molto formativa, anche se dolorosa...

c'è ne tanta di roba cosi purtroppo,dubito capiterà una sola volta nell'arco della carriera

[banryu79]

Originariamente inviato da khelidan1980

c'è ne tanta di roba cosi purtroppo,dubito capiterà una sola volta nell'arco della carriera

Ah, guarda, io la "carriera" proprio non la farò mai: la programmazione mi tocca solo come parte del lavoro che faccio e, purtroppo, non ho colleghi con cui condividere la materia.
L'unica finestra esterna che posso avere in questa realtà passa attraverso questa sezione del forum

[gugoXX]

Le buone regole Unix, sempre valide

Rule of Modularity: Write simple parts connected by clean interfaces.

Rule of Clarity: Clarity is better than cleverness.

Rule of Composition: Design programs to be connected to other programs.

Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

Rule of Simplicity: Design for simplicity; add complexity only where you must.

Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

Rule of Transparency: Design for visibility to make inspection and debugging easier.

Rule of Robustness: Robustness is the child of transparency and simplicity.

Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

Rule of Least Surprise: In interface design, always do the least surprising thing.

Rule of Silence: When a program has nothing surprising to say, it should say nothing.

Rule of Repair: When you must fail, fail noisily and as soon as possible.

Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

Rule of Diversity: Distrust all claims for “one true way”.

Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Ed espando quella sull'ottimizzazione.

Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
The most basic argument for prototyping first is Kernighan & Plauger's; “90% of the functionality delivered now is better than 100% of it delivered never”. Prototyping first may help keep you from investing far too much time for marginal gains.

For slightly different reasons, Donald Knuth (author of The Art Of Computer Programming, one of the field's few true classics) popularized the observation that “Premature optimization is the root of all evil”.[11] And he was right.

Rushing to optimize before the bottlenecks are known may be the only error to have ruined more designs than feature creep. From tortured code to incomprehensible data layouts, the results of obsessing about speed or memory or disk usage at the expense of transparency and simplicity are everywhere. They spawn innumerable bugs and cost millions of man-hours — often, just to get marginal gains in the use of some resource much less expensive than debugging time.

Disturbingly often, premature local optimization actually hinders global optimization (and hence reduces overall performance). A prematurely optimized portion of a design frequently interferes with changes that would have much higher payoffs across the whole design, so you end up with both inferior performance and excessively complex code.

In the Unix world there is a long-established and very explicit tradition (exemplified by Rob Pike's comments above and Ken Thompson's maxim about brute force) that says: Prototype, then polish. Get it working before you optimize it. Or: Make it work first, then make it work fast. ‘Extreme programming' guru Kent Beck, operating in a different culture, has usefully amplified this to: “Make it run, then make it right, then make it fast”.

The thrust of all these quotes is the same: get your design right with an un-optimized, slow, memory-intensive implementation before you try to tune. Then, tune systematically, looking for the places where you can buy big performance wins with the smallest possible increases in local complexity.

Prototyping is important for system design as well as optimization — it is much easier to judge whether a prototype does what you want than it is to read a long specification. I remember one development manager at Bellcore who fought against the “requirements” culture years before anybody talked about “rapid prototyping” or “agile development”. He wouldn't issue long specifications; he'd lash together some combination of shell scripts and awk code that did roughly what was needed, tell the customers to send him some clerks for a few days, and then have the customers come in and look at their clerks using the prototype and tell him whether or not they liked it. If they did, he would say “you can have it industrial strength so-many-months from now at such-and-such cost”. His estimates tended to be accurate, but he lost out in the culture to managers who believed that requirements writers should be in control of everything.

-- Mike Lesk

Using prototyping to learn which features you don't have to implement helps optimization for performance; you don't have to optimize what you don't write. The most powerful optimization tool in existence may be the delete key.

One of my most productive days was throwing away 1000 lines of code.

http://www.faqs.org/docs/artu/ch01s06.html

[RaouL_BennetH]

Beh, io posso solo esprimere ciò che ho fatto fino ad ora non essendo un programmatore professionista. Ho solo dovuto creare delle piccole applicazioni per l'azienda nella quale lavoro causa nessun bugdet da investire in informatica e, di conseguenza, su professionisti del settore.

A prescindere dagli strumenti e dai linguaggi che ho potuto utilizzare, ho proceduto semplicemente in questo modo:

1) Ho scritto i programmi in modo che facessero 'semplicemente' quello che veniva richiesto.

2) (per PGIBis ) Consegnati, e tutt'ora usati :P . Non sono stato pagato perchè prendo già un piccolo stipendio per la mia mansione principale (che NON è quella dell'homo informatico )

3) Sono certo che le due applicazioni rilasciate possono essere scritte, anzi, progettate molto meglio, ed una fase di refactor (ma solo a scopo personale) è già iniziata. Nel frattempo i programmini vengono usati quotidianamente.

Le regole che ho seguito:

Tutte quelle che mi sono state fornite qui e sui libri consigliati (sempre qui), ma, fondamentalmente, mi sono preoccupato prima di far funzionare quellaqualsiasicosa che scrivevo/pensavo per fare in modo che rispondesse alla richiesta che mi era stata fatta.

Per quanto possibile, ho cercato/cerco tutt'ora di scrivere nomi di variabili e metodi che abbiano un significato ben chiaro. Non ho ancora sufficiente esperienza con il TDD da potermi almeno fare un'idea da poter poi condividere con voi. Idem per i design pattern e metodi più eleganti nonchè produttivi.

Sicuramente ho imparato a separare quello che è la logica di funzionamento da l resto (tipo interfacce grafiche, connessioni ai db) tant'è che ho una decina di librerie abbastanza 'elastiche' da poter coprire quasi tutte le piccole esigenze dell'azienda.

Non avete idea di quanto mi piacerebbe poter, non dico farne parte, osservare e stare a contatto per qualche giorno con un team di sviluppo o con qualcuno di voi (non faccio nomi, ma siete in tanti) mentre lavora

RaouL.

[banryu79]

Originariamente inviato da RaouL_BennetH

Non avete idea di quanto mi piacerebbe poter, non dico farne parte, osservare e stare a contatto per qualche giorno con un team di sviluppo o con qualcuno di voi (non faccio nomi, ma siete in tanti) mentre lavora

Siamo in due, se è per questo

[_Claudio]

Originariamente inviato da yorkeiser

Butto la mia su quello che NON si dovrebbe fare: recentemente, a causa di modifiche legislative in ambito assicurativo, ho dovuto mettere mano a un accrocchio (una serie di programmoni) VB6 ( ) che si preoccupano di rinnovare in automatico le polizze dei clienti. Ebbene, io non avevo mai visto una funzione di 1800 righe di codice composta esclusivamente da if annidati fino al 14° livello (li ho contati) e con indentazione assolutamente casuale. Per inciso, l'IDE VB6 non ha strumenti di indentazione automatica.
Da qui due regoline: in primis, indentare il codice.
In secundis: imparare a strutturare i dati in maniera furba e soprattutto riutilizzabile, pensando sempre al fatto che prima o poi qualcun'altro metterà le mani sul tuo lavoro. E cercare di non utilizzare variabili globali, nel caso il linguaggio lo permetta.

Rifarlo da 0?
Per poi non contare le implicazioni legislative che ci sono nel modificare il codice altrui... c'è da stare attenti, ti danno da modificare un programma e ti arriva un avviso di garanzia a casa...

Personalmente penso che il progettare bene ciò che c'è da fare stendendo un minimo di progetto concettuale di quello che va realizzato (i vari attori che si trasformeranno nelle varie classi o funzioni e file sorgenti distinti) vale 1000 regole di buona programmazione.

Ho visto "soluzioni" scritte "a corpo", senza che nemmeno sia passato per la mente a chi ha scritto l'accrocchio di ragionare 5 minuti sul problema, con complessità n^n^n... quando pensandoci e eliminando casi particolari si raggiungeva un n^2. E non parlo di semplici programmini ma di programmi per il calcolo scientifico che se li sviluppava la catechista venivano meglio.

Se invece si tratta di programmini semplici, tipo "dar luce" ad una libreria di compressione grafica (costruirgli l'interfaccia attorno) allora si possono scrivere anche a corpo con qualche accorgimento.

[VICIUS]

Originariamente inviato da yorkeiser

Butto la mia su quello che NON si dovrebbe fare: recentemente, a causa di modifiche legislative in ambito assicurativo, ho dovuto mettere mano a un accrocchio (una serie di programmoni) VB6 ( ) che si preoccupano di rinnovare in automatico le polizze dei clienti. Ebbene, io non avevo mai visto una funzione di 1800 righe di codice composta esclusivamente da if annidati fino al 14° livello (li ho contati) e con indentazione assolutamente casuale. Per inciso, l'IDE VB6 non ha strumenti di indentazione automatica.

Aggiungo che se si usano ide come visual studio è buona cosa imparare a dare nomi decenti a tutti i controlli. Modificare quattromila righe di codice piene di Form32, CmdButton7, Label19 è veramente frustrante.

[yorkeiser]

Originariamente inviato da RaouL_BennetH

Non avete idea di quanto mi piacerebbe poter, non dico farne parte, osservare e stare a contatto per qualche giorno con un team di sviluppo o con qualcuno di voi (non faccio nomi, ma siete in tanti) mentre lavora

Ti dirò, io invece ne sono uscito molto volentieri, ora mi occupo solo saltuariamente di programmazione vera e propria.
Non fraintendermi, progettare un programma e poi svilupparlo, da soli o in team, è un'attività molto interessante (beh, almeno per me), ma a volte le "condizioni al contorno" che trovi quando lo fai da professionista ti portano a livelli di stress che neanche immagini. Requisiti non chiari, che cambiano in continuazione, anche nello stesso giorno della messa in produzione. Richieste da parte di gente totalmente incompetente, che a due giorni dalla consegna ti dice "ma dai, secondo me è facile" non avendo idea che quella richiesta sta rovesciando il mondo. Gestionali da 20mila righe di codice testati in due ore, che vanno in produzione (immancabilmente) pieni di bachi. Gente che decide di cambiare il database da mettere sotto il culo dell'applicativo il giorno prima della messa in produzione (per un problema sulle licenze, realmente successo). Tutte realtà purtroppo molto diffuse, per mia esperienza. Ripeto, programmare è un'arte fantastica ed ho molta stima dei programmatori (almeno di quelli bravi, e ce ne sono tanti). E' la realtà a contorno che, secondo me, spesso trasuda incompetenza e superficialità, in puro italian style. Mi chiedo ancora come sia possibile che nel 2009 molti progetti informatici, anche piuttosto grossi, siano gestiti da gente che non ha manco idea di cosa sia un array, una variabile, una classe, figuriamoci arrivare a concetti più avanzati.