Sjuanez ha scritto:Ho riportato quello che so, sarebbe bello sentire un professionista come
DarwinNE a riguardo.
Beh, io non sono mica un professionista. Per lavoro faccio tutt'altro, anche se avere un minimo di dimestichezza con progettini software aiuta quando devo affrontare un problema anche in ambito professionale.
La domanda è partita da uno stile per scrivere gli if e poi è evoluta sulla scrittura del codice in generale. Quel poco che ho imparato seguendo un po' quello che succedeva nella programmazione dai primi anni 90 ad oggi, è che intanto ci sono delle mode che vanno e vengono. Poi probabilmente per progetti non banali è una buona idea adottare un approccio pragmatico.
Posso parlare per quel poco che ho imparato con FidoCadJ. Come sapete, si tratta di un progettino di circa 50k linee di codice in Java. Certe parti sono abbastanza pulite e chiare, altre meno. Per esempio, il parser attualmente non è molto ben scritto. Le scelte fatte nel 2007 hanno funzionato subito molto molto bene, ma hanno supportato male certe estensioni del linguaggio. Il risultato è che ci sono copia/incolla, una lunga sequenza di if/elseif/else imbricati in maniera non facile da seguire, variabili di stato dal significato oscuro. Però è testato quotidianamente da tutti voi, funziona, ed adesso come adesso nessuno ha voglia di riscriverlo da zero.
In altri punti il codice è modulare, organizzato in maniera che mi pare chiara e abbastanza ben definita (per esempio, l'esportazione verso formati vettoriali). Nel 2014 c'è stata un refactoring molto profondo che ha coinvolto praticamente tutto il programma, permettendo di condividere moltissimo codice con l'applicazione Android. Certe cose ci sono sembrate ragionevoli, altre meno. Insomma, è probabilmente codice buono, ma non perfetto.
Bisogna poi ricordare che la maggior parte delle linee di codice ha poco di algoritmi interessanti: è codice di una noiosità sconvolgente, per piazzare un bottone in maniera corretta in una finestra alle varie risoluzioni e dimensioni etc.
Ci sono cose che io non accetto assolutamente in un commit FidoCadJ e ci sono stati dei contributi in passato che sono stati ripresi perché contenevano cose inguardabili. C'è anche codice che non ho scritto io, in cui io avrei fatto scelte diverse dal programmatore che l'ha scritto, ma che mi paiono assolutamente accettabili e lodevoli. Invece sono abbastanza inflessibile sullo stile di scrittura "tipografico", sulle indentature e cose del genere, che devono rimanere il più possibile coerenti all'interno di tutto il progetto. Quelle sono state scelte all'inizio ed adesso non si cambiano. Ecco le regole scritte nel README:
- Codice: Seleziona tutto
- the code should be compatible with Java 1.7
- tab set to 4 spaces
- blocks delimited by curly braces are indented as follows:
for(i=0; i<10; ++i) { // starting brace here
// indented code (4 spaces)
System.out.println("I counted up to "+i);
} // close brace here at the same level of the 'for'
- methods are indented as follows:
void dummy(int i, int j)
{ // put the starting brace here
System.out.println("Indent code");
} // put the closing brace here
- switches are indented as follows:
int dummy(int i)
{
int j;
switch(i) {
case 1:
j=3;
break;
case 2:
j=2;
break;
default:
j=0
}
return j;
}
- the class names always start with a capital letter, and so does methods
- variables never start with a capital letter
- an instance of the class does have its first letter in lower case
- public classes and methods should be documented with Javadoc syntax
- no lines longer than 80 characters
- commits should not break the build
- each commit *MUST* include a log
- predilect simplicity to unnecessary complication
- predilect quality to quantity
- discuss what you want to do BEFORE start coding
- documentation is important. Try to improve it and keep it up-to-date
Io mi vergogno per certe parti del codice di FidoCadJ, però penso che se avessi cercato di scrivere subito codice perfetto non solo non ci sarei riuscito, ma FidoCadJ non sarebbe mai venuto alla luce. Ai livelli di Donald Knuth c'è solo lui ed il Padreterno, solo che sul secondo diversi hanno in passato espresso dubbi sull'esistenza.
Mi pare che nessuno ha parlato dell'analisi automatica del codice. Non fa miracoli, ma permette di evitare certe cattive pratiche ed in passato ha permesso di eliminare alcuni bug in FidoCadJ che altrimenti sarebbero passati inosservati. Ecco il risultato dell'analisi dello stato attuale dei sorgenti, fatta con PMD:
https://sourceforge.net/p/fidocadj/code ... format=rawSi vede chiaramente che io e gli altri sviluppatori (ma soprattutto io) abbiamo una certa tendenza a scrivere classi dio
Però alla fine non ci sono troppi messaggi
Quando posso, faccio anche analisi dinamica (valgrind per programmi in C++).
Insomma si fa quel che si può: sulle parti critiche e gli algoritmi si fa girare tutto su carta, sulle parti noiose facilmente testabili (GUI) si cerca di scriverle in fretta e provarle, quello che si può testare in maniera automatica lo si fa. Si cerca di capire il meglio possibile la documentazione malscritta della tal tecnica per fare il click&draw, si fa il possibile per tenere aggiornata la documentazione nelle lingue (umane) che si parlano. Si rilegge il codice del giorno prima per vedere se ci sono casi dimenticati, si cerca di scovare il bug che il tale ha segnalato una settimana fa, si migliorano i commenti del codice scritto tre anni fa ed ormai poco comprensibile. Ogni tanto si studia la tecnica vecchia e nuova, perché i linguaggi (e le mode
) evolvono e c'è sempre qualcosa da imparare, senza troppi preconcetti e regole troppo rigide.
Tornando alla domanda sugli if
, per quanto mi riguarda, tendo a preferire gli and e sono d'accordo con
simo85 e con
TardoFreak, non mi piace usare if imbricati se non c'è codice che debba essere eseguito solo con una condizione e non con l'altra. Non mi piace usare una variabile, trovo che non aggiunga nulla alla leggibilità e renda solo il codice più prolisso, a meno che non ci siano ragioni per giustificarne la presenza (per esempio perché la stessa condizione è usata in un secondo tempo).
P.S. Guardate che schifezza che è addString (per avere le indentature giuste, bisogna aprire il file con un editor che abbia il tab configurato a 4 spazi):
https://sourceforge.net/p/fidocadj/code ... tions.javaQuella è colpa mia, mi cospargo il capo di cenere
Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)
).
pigreco]=π
Ci tengo tanto a questo forum e alle persone che lo frequentano e soprattutto, ne apprezzo i toni cordiali e rispettosi che lo rendono una vera e propria risorsa, nonché un posto piacevole per incontrare persone piacevoli.
