View Full Version : [GENERALE] Regole di buona programmazione
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 :)
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 (http://docs.factorcode.org/content/article-cookbook-philosophy.html)
Effective Java (http://books.google.com/books?id=ZZOiqZQIbRMC)
Google C++ Style Guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml)
anche questo link è ottimo http://sourcemaking.com/
La prima regola della buona programmazione è finire il programma.
DanieleC88
28-07-2009, 14:42
anche questo link è ottimo http://sourcemaking.com/
Simpatico il link! Ctrl+D. :D
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'. :stordita:
Mai visto un programma finito.
A meno che per 'finito' non intendiamo 'fatturato' e/o 'che nessuno utilizza'. :stordita:
O a meno che per 'finito' non si intenda che ci si è messa una pietra sopra :p
Mai visto un programma finito.
A meno che per 'finito' non intendiamo 'fatturato' e/o 'che nessuno utilizza'. :stordita:
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".
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
28-07-2009, 15:16
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.
:Puke:
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
28-07-2009, 16:18
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 ( :cry: ) 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
28-07-2009, 17:24
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 :asd:
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
28-07-2009, 17:28
E meno male che lo chiamano software... roba del genere è inamovibile e immodificabile per il semplice fatto che è inguardabile :asd:
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
28-07-2009, 17:55
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 :)
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
28-07-2009, 18:19
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 :D ) 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
28-07-2009, 18:30
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
28-07-2009, 18:37
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 ( :cry: ) 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.
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 ( :cry: ) 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
28-07-2009, 18:46
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.
_Claudio
28-07-2009, 18:52
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.
Bisogna ringraziare il diplomificio italico e la svalutazione del buon laureato medio nel mondo del lavoro.
^TiGeRShArK^
28-07-2009, 18:53
Per me l'unica regola aurea che riassume tutto in una parola è KISS (http://en.wikipedia.org/wiki/KISS_principle).
yorkeiser
28-07-2009, 19:00
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.
Pienamente d'accordo, quanti ne ho visti purtroppo. Ed aggiungo che anche i nomi di classi, attributi e metodi devono essere significativi. Ho trovato metodi chiamati SaltaQua(), MetodoAggiunto(), Funz<nome e cognome del programmatore>(). E poi aggiungere commenti, e che siano utili. Qualche giorno fa mi sono fatto un mare di risate trovando un commento che suonava più o meno:
// Non so perchè funziona, però funziona
:mbe:
franksisca
28-07-2009, 19:32
Pienamente d'accordo, quanti ne ho visti purtroppo. Ed aggiungo che anche i nomi di classi, attributi e metodi devono essere significativi. Ho trovato metodi chiamati SaltaQua(), MetodoAggiunto(), Funz<nome e cognome del programmatore>(). E poi aggiungere commenti, e che siano utili. Qualche giorno fa mi sono fatto un mare di risate trovando un commento che suonava più o meno:
// Non so perchè funziona, però funziona
:mbe:
muhauhauauauahu.....io uso MVC e nomi delle variabili/metodi autoesplicativi.
solo raramente commento qualche formula...ma solo quando mi rendo conto che nemmeno io potrei ricostruirlo :D
DanieleC88
29-07-2009, 01:33
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.
Be', insomma, con un minimo di raziocinio penso che sia una cosa che chiunque è in grado di capire. Io a 14 anni avevo già imparato a farlo e avevo una mia sottospecie di "coding style"... :D
Be', insomma, con un minimo di raziocinio penso che sia una cosa che chiunque è in grado di capire. Io a 14 anni avevo già imparato a farlo e avevo una mia sottospecie di "coding style"... :D
Sarà anche banale come cosa ma non tutti sembrano arrivarci perché a me è già capitato più di una volta. :(
DanieleC88
29-07-2009, 10:41
Sarà anche banale come cosa ma non tutti sembrano arrivarci perché a me è già capitato più di una volta. :(
Spero che non capiti mai a me, o al monitor gli faccio fare un bel volo dalla finestra. :D
Pienamente d'accordo, quanti ne ho visti purtroppo. Ed aggiungo che anche i nomi di classi, attributi e metodi devono essere significativi. Ho trovato metodi chiamati SaltaQua(), MetodoAggiunto(), Funz<nome e cognome del programmatore>(). E poi aggiungere commenti, e che siano utili. Qualche giorno fa mi sono fatto un mare di risate trovando un commento che suonava più o meno:
// Non so perchè funziona, però funziona
:mbe:
LOL, mi ricorda del codice che ogni tanto spunta fuori da http://thedailywtf.com/ :D
Comunque, credo che la regola d'oro della programmazione (vedi in firma) sia sempre da tenere a mente o, meglio, incollata allo schermo di ogni programmatore. :p
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.
La questione della documentazione è un nodo che mi lascia perplesso: è noto che sia buona consuetudine scrivere documentazione mentre si scrive il codice anziché aggiungerla tutta insieme dopo, però io MOLTO raramente scrivo codice soddisfacente alla prima passata. Allora dovrei aggiornare anche i commenti ad ogni modifica e questo non è produttivo.
Insomma la regola "scrivi la documentazione mentre scrivi il codice" secondo me vale solo per programmatori esperti per i quali la procedura/funzione N scritta la prima volta e commentata avrà buona probabilità di rimanere quella definitiva.
Inoltre proprio l'approccio eXtreme Programming che promuove la scrittura mirata all'ottenimento della soluzione del problema il più presto possibile in modo da sottoporre il "semi-lavorato" al cliente, richiede successive e quasi certe modifiche del codice, quindi a che scopo commentarlo subito?
Spero che non capiti mai a me, o al monitor gli faccio fare un bel volo dalla finestra. :D
Dovresti gettare l'autore del codice che almeno fai un po' di esercizio fisico. Il monitor, poverino, non ne ha colpa :O
DanieleC88
29-07-2009, 11:01
Dovresti gettare l'autore del codice che almeno fai un po' di esercizio fisico. Il monitor, poverino, non ne ha colpa :O
È sottointeso che lo faccio solo se il monitor non è quello mio personale ( :ciapet: ), e comunque è chiaro che getterei volentieri l'autore del codice e non il monitor, ma, in assenza di alternative, almeno mi sfogo. :O
:D
banryu79
29-07-2009, 11:07
Inoltre proprio l'approccio eXtreme Programming che promuove la scrittura mirata all'ottenimento della soluzione del problema il più presto possibile in modo da sottoporre il "semi-lavorato" al cliente, richiede successive e quasi certe modifiche del codice, quindi a che scopo commentarlo subito?
Io penso infatti che sia meglio sforzarsi di rendere "parlante" il codice stesso, extreme programming o meno.
Quando possibile tento sempre di applicare la tecnica di refactoring nota come "extract method" nelle piccole porzioni di codice precedute da un commento: il nome del nuovo metodo diventa il commento.
Inoltre ho notato che questo mi da delle opportunità di riutilizzo del metodo stesso, abbasando un po' le duplicazioni di codice. Lo faccio mentre stendo il codice.
Non è la panacea a tutti i mali, ma, come si suol dire, meglio che un calcio negli zebedei :asd:
khelidan1980
29-07-2009, 12:03
io ho notato una cosa,quando mi rendo conto che una porzione di codice che sto scrivendo necessita di esser commentata,99 su 100 sto scrivendo una schifezza! :D
Inoltre proprio l'approccio eXtreme Programming che promuove la scrittura mirata all'ottenimento della soluzione del problema il più presto possibile in modo da sottoporre il "semi-lavorato" al cliente, richiede successive e quasi certe modifiche del codice, quindi a che scopo commentarlo subito?
le metodologie agili hanno sicuramente dei vantaggi ma non mi piace l'approccio "talebano" alle stesse.
il fatto che i commenti siano "sconsigliati" ad esempio è un aspetto che non mi piace.
rilasciare il prodotto a piccole dosi mi sta bene, ma non è detto che dovrai sempre rimettere mano al codice per stravolgerlo.
i commenti se non li scrivi subito finisce che non li metti più, se non quando ti tocca leggere e capire codice altrui e già che ci sei fai l'opera pia di commentarlo per le generazioni future.
peraltro bastano poche righe, non si deve perdere tempo a scrivere il commento e non si deve esagerare nel dettaglio, almeno in fase di scrittura del codice. eventualmente, in fase di stesura della documentazione, si va più nel dettaglio
le metodologie agili hanno sicuramente dei vantaggi ma non mi piace l'approccio "talebano" alle stesse.
il fatto che i commenti siano "sconsigliati" ad esempio è un aspetto che non mi piace.
Non ho mai sentito di nessuno dentro la comunità agile che sconsigli di usare i commenti.
khelidan1980
29-07-2009, 12:59
Non ho mai sentito di nessuno dentro la comunità agile che sconsigli di usare i commenti.
bhe è implicito penso,il codice deve essere parlante di suo
Credo che il commento serva più che altro quando un determinato algoritmo/metodo/classe per poter essere ben capito necessiti di competenze notevoli dell'ambito applicativo del software,che possono essere molto trasversali all'informatica,tipo quello bancario
bhe è implicito penso,il codice deve essere parlante di suo
Scoraggiare un certo tipo di commenti non significa impedire totalmente l'uso dei commenti. Il codice dovrebbe essere chiaro in modo che non servano i classici commenti tipo:
// incrementa di uno il contatore degli utenti
u += 1
Qui sopra c'è una chiara duplicazione tra codice e commento. Questo crea un problema di dipendenza tra i due. Non puoi modificarne uno senza toccare anche l'altro.
Credo che il commento serva più che altro quando un determinato algoritmo/metodo/classe per poter essere ben capito necessiti di competenze notevoli dell'ambito applicativo del software,che possono essere molto trasversali all'informatica,tipo quello bancario
Perfettamente d'accordo. Sono questi commenti che andrebbero inseriti a palate nel codice.
banryu79
29-07-2009, 14:56
Perfettamente d'accordo. Sono questi commenti che andrebbero inseriti a palate nel codice.
Sì questo lo trovo neccessario anch'io.
Quello che intendevo è che con qualche tecnica scopiazzata dal refactoring (le sto provando da un po') qualcosa di buono che per me funziona l'ho trovato, in particolare quella faccenda dell'estrarre i metodi.
All'inizio tendevo a esagerare, poi ci ho preso le misure e adesso mi viene naturale, che ho trovato un mio equilibrio. I vantaggi che ho rispetto a prima è che già durante la prima implementazione di una classe che, sulla carta (o nella testa, a seconda dei casi) aveva delle precise responsabilità a cui fare fronte, salta fuori che alcune di queste sono in realtà date dalla collaborazionedi responsabilità "più piccole" che non avevo identificato a desing time: il risultato è che spesso queste unità più piccole sono presenti anche altrove, nel qualcaso dopo la codifica in piccoli metodi capita che emerga l'evidenza e la neccessità di raggrupparli in una classe.
A seconda dei casi può essere una classe locale a quella originaria oppure una classe a livello di package.
E di solito tutto comincia col rendermi conto che il metodo che sto scrivendo fa più di una cosa, oppure comincia a sembrarmi troppo lungo, oppure comincio a vedere che nel corpo del metodo ci sono diversi blocchi di codice preceduti da una o due righe di commento.
Tutto qua, comunque.
malocchio
29-07-2009, 18:46
Siamo in due, se è per questo :)
Tre :O
Pienamente d'accordo, quanti ne ho visti purtroppo. Ed aggiungo che anche i nomi di classi, attributi e metodi devono essere significativi. Ho trovato metodi chiamati SaltaQua(), MetodoAggiunto(), Funz<nome e cognome del programmatore>(). E poi aggiungere commenti, e che siano utili. Qualche giorno fa mi sono fatto un mare di risate trovando un commento che suonava più o meno:
// Non so perchè funziona, però funziona
:mbe:
Io non riesco a evitare di scrivere commenti ironici, ma che comunque vogliono dire qualche cosa :D.
Le battutine ci stanno sempre nel codice. Una volta, prima di una bella trafila di if-else-if-else (che secondo me non si poteva evitare) ho scritto
//XXX inizia il rosarioMi diverto così. :fagiano:
Poi ci sta che NetBeans mi metta quel commento in tasklist così quando andrò a scorrerla più avanti mi ricorderò di ripensare a una possibile soluzione migliore.
Sinceramente la parte riguardante ambiti meno informatici la preferisco mettere in documentazione (Javadoc rulez), che va messa SEMPRE, a meno che non si tratti di un metodo auto-esplicativo o che comunque ha un nome che viene utilizzato anche in classi più standard e quindi si riesce chiaramente a risalire alla funzionalità.
Per il resto non ho regole scritte o marchiate a fuoco nel cervello, vado MOLTO a buon senso, che penso non mancarmi.
Una buona norma e' quella di mettere le guardie ai parametri di ingresso delle funzioni.
Altrimenti il software finisce per combinare casini come questo
http://img.photobucket.com/albums/v314/gugogugo/fail-owned-bargain-fail.jpg
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.
mi ricorda qualcosa... :asd:
http://thedailywtf.com/Articles/The_Hotel_%28reservation_system%29_From_Hell.aspx
mi ricorda qualcosa... :asd:
http://thedailywtf.com/Articles/The_Hotel_%28reservation_system%29_From_Hell.aspx
Gli è andata ancora di lusso. Io ho visto il "gestionale" del magazzino di una società da 200 milioni di euro di fatturato l'anno: un foglio excel usato a mo' di form.
DanieleC88
30-07-2009, 02:03
Gli è andata ancora di lusso. Io ho visto il "gestionale" del magazzino di una società da 200 milioni di euro di fatturato l'anno: un foglio excel usato a mo' di form.
Che sia usato fino a questo livello mi stupisce un po', lo ammetto, ma in effetti ho visto diverse volte chi pensa che Excel sia la panacea (e, per me che ci ho dovuto mettere le mani da Java, la fonte) di tutti i mali...
banryu79
30-07-2009, 09:33
mi ricorda qualcosa... :asd:
http://thedailywtf.com/Articles/The_Hotel_%28reservation_system%29_From_Hell.aspx
Sono esterefatto: non tanto per il casino in se, quante per il fatto che l'autore doveva essere tedesco o giù di li (dai pochi nomi intellegibili di alcuni form).
Io tra i clienti con cui ho a che fare ho dei tedeschi: sono i più "rognosi" perchè sono di una precisione maniacale e senza una direttiva letta da un manuale non si spostano di un millimetro.
Percui sono rimasto basito leggendo 'sta roba. (Sempre ammesso che questi in realtà non avessero pure un secondo database: quello che teneva traccia della nomenclatura dei form del progetto :asd: )
malocchio
30-07-2009, 09:34
Una buona norma e' quella di mettere le guardie ai parametri di ingresso delle funzioni.
Altrimenti il software finisce per combinare casini come questo
http://img.photobucket.com/albums/v314/gugogugo/fail-owned-bargain-fail.jpg
:asd:
Io in questi giorni devo (purtroppo) mettere le mani su questa della roba...
Un breve stralcio per voi (Notare la finezza al primo rigo)
if (cod_tipo_uo.equals("21") || !cod_tipo_uo.equals("21")){
if (itemComboTip.equals("")){
tipoPtf = "";
sottoTtipolPtf = "";
if (cod_tipo_uo.equals("A3")|| cod_tipo_uo.equals("94")){
if (!JFWebContextUtil.consumeFlowArea(request, "CodItem").isEmpty() &&
JFWebContextUtil.consumeFlowArea(request, "CodItem")!= null ){
String val = (String) JFWebContextUtil.consumeFlowArea(request, "CodItem").toArray() [0];
val = val.substring(3,val.length());
JFWebContextUtil.informFlowArea(request, val, "tipoRicerca");
/**/
if (!val.equals("TUTTI")){
tipoPtf = val.substring(0,2);
if (val.length()== 5){
sottoTtipolPtf = val.substring(3,5);
}else if (val.length()== 2){
sottoTtipolPtf = "";
}
if (sottoTtipolPtf.equals("")){
JFWebContextUtil.informFlowArea(request,cod_tipo_uo +'-'+ tipoPtf, "tipoRicerca");
}else JFWebContextUtil.informFlowArea(request,cod_tipo_uo +'-'+ tipoPtf+'-'+sottoTtipolPtf, "tipoRicerca");
}
/***/
}
}else JFWebContextUtil.informFlowArea(request, "TUTTI", "tipoRicerca");
}
Auguri a me :D
banryu79
30-07-2009, 12:35
if (cod_tipo_uo.equals("21") || !cod_tipo_uo.equals("21")){...}
E' un classico caso di pentimento repentino aggravato da fobia della cancellazione del sorgente con scappellamento a destra :O
yorkeiser
30-07-2009, 12:39
if (cod_tipo_uo.equals("21") || !cod_tipo_uo.equals("21")){...}
E' un classico caso di pentimento repentino aggravato da fobia della cancellazione del sorgente con scappellamento a destra :O
Con indentazione antani brematurata :asd:
_Claudio
30-07-2009, 12:40
if (cod_tipo_uo.equals("21") || !cod_tipo_uo.equals("21")
Mio Dio ma... ma... è terribile!!!
banryu79
30-07-2009, 12:43
Mio Dio ma... ma... è terribile!!!
No, no, stia tranquillo si guarisce subito e completamente: basta una settimana di sodomizzazione forzata con apparato scartavetrante :fagiano:
Comunque si vede che chi ha scritto quel sorgente non sa nulla di refactoring, con una semplificazione poteva ridurre il tutto a questa perla:
if (true != false) {...}
Almeno si salvava dalla "identazione antani brematurata" :asd:
Certo che vista in questa forma denuncia un incredibile scetticismo...
_Claudio
30-07-2009, 12:55
Ora mi è ancora più chiaro il perchè i lavori IT sono svalutati e considerati stupidi e inutili, e una laurea tecnica nel settore è considerata poco meno che nulla.
Finchè c'è gente magari laureata disposta ad essere pagata 900€ al mese per scrivere certe boiate.
Almeno lo facessero gratis, potrebbero presentarsi e dire:"io sono laureato in ..., ho studiato anni ma comunque non so un'emerita ceppa di quello che fate, non sono in grado di comprendere neppure sotto tortura, scriverò del codice pessimo dettatomi dal pupazzo gnappo che tengo nella mia 24 ore, ma lo farò gratis per dignità"
Noi "professionisti seri" vivremmo tutti più felici (e ricchi). :sofico:
Frank1962
30-07-2009, 13:28
Il mio professore di Linguaggi & Compilatori al 2° semestre del 3° anno della triennale ci disse " .....ma cosa credete? iscriversi a un corso di laurea di informatica non serve a diventare dei buoni programmatori, per questo basta comprarsi un manuale...." ....ancora devo capire a che cosa serve la famigerata laurea in informatica, ma non me lo poteva dire al 1° semestre del 1° anno sta roba :muro:
cdimauro
30-07-2009, 13:45
Mio Dio ma... ma... è terribile!!!
Macché terribile. Ci si lamenta sempre della teoria, preferendole la pratica, e una volta tanto che si vede applicata una tautologia si grida allo scandalo. :sob:
_Claudio
30-07-2009, 13:50
Macché terribile. Ci si lamenta sempre della teoria, preferendole la pratica, e una volta tanto che si vede applicata una tautologia si grida allo scandalo. :sob:
:D :D
Dici bene, chi ha scritto quell'accrocchio sicuramente ha voluto dimostrare proprio questo... :sofico: :muro:
_Claudio
30-07-2009, 13:55
Chi ci dice invece che invece vale la logica di Lukasiewicz nel valutare la equals e quindi quell'enunciato porta informazioni?:oink:
Mai assumere il mondo chiuso, e mai basarsi sul FOL per descrivere il mondo intero...:D
tsè, principianti :D:D:D:D
(ammesso che si possa fare) Il massimo sarebbe un overload della .equals(), che cambia il valore durante il primo confronto, oppure che esegue qualcosa di "importante".
:D E' chiaramente un codice destinato ad essere eseguito in un contesto concorrente! L'if viene eseguito se e solo se un Thread cambia il valore di cod_tipo_uo esattamente tra il primo ed il secondo if. :D
EDIT: No, c'è un || e io ho letto &&. :cry: E' l'età.
EDIT 2: Non viene eseguito se un Thread cambia il valore tra il primo e il secondo if.
malocchio
30-07-2009, 15:59
:D E' chiaramente un codice destinato ad essere eseguito in un contesto concorrente! L'if viene eseguito se e solo se un Thread cambia il valore di cod_tipo_uo esattamente tra il primo ed il secondo if. :D
La nuova frontiera della sincronizzazione :asd:
banryu79
30-07-2009, 16:01
Lo ripeto e lo ribadisco: è solo scetticismo.
Giustamente chi gli garantisce la validità del principio "Tertium non datur"? Non si sa mai... :O
Lo ripeto e lo ribadisco: è solo scetticismo.
Giustamente chi gli garantisce la validità del principio "Tertium non datur"? Non si sa mai... :O
In effetti l'introduzione del booleano "maybe" lo troverebbe preparato.
khelidan1980
30-07-2009, 16:18
Ora mi è ancora più chiaro il perchè i lavori IT sono svalutati e considerati stupidi e inutili, e una laurea tecnica nel settore è considerata poco meno che nulla.
Finchè c'è gente magari laureata disposta ad essere pagata 900€ al mese per scrivere certe boiate.
Almeno lo facessero gratis, potrebbero presentarsi e dire:"io sono laureato in ..., ho studiato anni ma comunque non so un'emerita ceppa di quello che fate, non sono in grado di comprendere neppure sotto tortura, scriverò del codice pessimo dettatomi dal pupazzo gnappo che tengo nella mia 24 ore, ma lo farò gratis per dignità"
Noi "professionisti seri" vivremmo tutti più felici (e ricchi). :sofico:
Guara imho quelle perle di cui sopra sono spesso eredità di codice legacy risalente agli anni del "boom" dove si prendeva tizio qualunque e lo si metteva a fare lo sviluppatore dopo un corso java di sei mesi ad andar bene...
banryu79
30-07-2009, 17:03
Guara imho quelle perle di cui sopra sono spesso eredità di codice legacy risalente agli anni del "boom" dove si prendeva tizio qualunque e lo si metteva a fare lo sviluppatore dopo un corso java di sei mesi ad andar bene...
E di questa perla [link] (http://thedailywtf.com/Articles/A-Mans-Array.aspx) che mi dici?
Ho anche uno slogan: BruteForce, per il developer che non deve chiedere mai!
Davvero non so come sia possibile che esita roba di sto genere: cioè uno non può non sapere che non esitono gli array...
A me viene un forte sospetto ormai: non è che certi "professionisti" programmano a bella posta così, in modo da costringere gli sventurati clienti a dover chiedere nuovamente il loro aiuto (e a pagare il relativo ingaggio) per ogni minima modifica?
khelidan1980
30-07-2009, 17:08
E di questa perla [link] (http://thedailywtf.com/Articles/A-Mans-Array.aspx) che mi dici?
Ho anche uno slogan: BruteForce, per il developer che non deve chiedere mai!
Davvero non so come sia possibile che esita roba di sto genere: cioè uno non può non sapere che non esitono gli array...
A me viene un forte sospetto ormai: non è che certi "professionisti" programmano a bella posta così, in modo da costringere gli sventurati clienti a dover chiedere nuovamente il loro aiuto (e a pagare il relativo ingaggio) per ogni minima modifica?
oddio gli antipattern esistono eccome,credo però che siano applicati consapevolmente solo nell'1% dei casi,per il resto è talento naturale :D
Quello sembra codice generato da un tool. Insomma, uno deve essere proprio un masochista per scrivere una cosa del genere a mano.
banryu79
30-07-2009, 17:16
Quello sembra codice generato da un tool.
Si ti prego, fa che sia così :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.