Puso:
A volte fatico a comprendere ....
... non vedo cosa ci sia da comprendere ... :
Il committente da delle specifiche e delle regole e o tu le segui o "butti al cesso" il lavoro che hai fatto e non te lo pagano.
Guglielmo
maubarzi:
In genere certe regole sembrano delle pignolerie in realtà nascondono dei motivi più profondi.
... se conosci l'ambiete "automotive" o quello "medicale" o, peggio "aerospaziale" o "nucleare" ... sai bene che hanno validissimi motivi per creare queste regole e che la sola "pignoleria" non c'entra nulla 
Guglielmo
allora sono normale
non ho committenti ne commitenze.....in questo ambito.....posso fare l'hobbysta.
Puso:
non ho committenti ne commitenze.....in questo ambito.....posso fare l'hobbysta.
e appena ti pagano a righe di codice vedi come abbandoni i ternari e metti gli if then else con le parentesi a capo con spazi e commenti per fare volume.... 
Puso:
addirittura proibito?????
essendo facile causa di errori, è comprensibilissimo il perchè in alcuni progetti è addirittura proibito
ho la 3 media...ho comprato Arduino 2 anni fà...sono solo un hobbysta.
Ma sono curioso.
e fai benissimo
io sto tifando per te su tutto il topic, non si era capito?
lo avevo capito...ma mi sto ascoltando l'ultima luna di lucio dalla...per riprodurlo sul mio topic.
maubarzi:
Questo è vero... in teoria... nella pratica non ho mai trovato casi dove la leggibliità fosse minata principalmente da questi problemi.
Mi viene il sospetto che tu non abbia mai realmente lavorato in un team di sviluppo, dove fare un codice leggibile (e magari anche autodocumentato) è non solo un modo di evitare perdite di tempo per "capire" cosa faccia e come lo fa, ma anche evitare bug che diventano difficili da identificare "a vista" rendendo quindi il bug fixing una operazione più complessa e lunga (ed il tempo è denaro nelle commesse...). Ed anche per evitare i vaffanculo dei tuoi compagni di team, per cui spero che tu programmi da solo o con tuo fratello, altrimenti ti vedo in pericolo con sti criteri...
Vedi, io sono stato programmatore per anni (ora a 50 e passa anni, lo sono comunque ancora ma più che altro per passione e per restare aggiornato), ora sono software architect e team leader, e addetto anche ai processi di produzione del software (metodologia SCRUM), e se un mio programmatore si mette a fare codice che non si legge decentemente lo mando a rifarlo daccapo prima che qualcuno degli altri alla prima volta che deve metterci mano lo vada a "redarguire", o peggio se per fare il figo con la compattazione si trovano dei bug che ci si mette una settimana a sistemarli.
Reputo la scelta di if then else piuttosto che di operatori ternari piuttosto che di mettere le parentesi in un modo o in un altro (a me ad es. piace metterle sempre le graffe anche se nell'if c'è una sola istruzione) una questione marginale.
Non è "centrale" ovviamente ma neanche "marginale" (per i motivi esposti sopra). Se una if è semplice ed in genere applicata ad una valorizzazione ci può anche stare, si legge comunque abbastanza bene. Ma se nella if ci sono più condizioni magari anche lunghe, e con i due valori altrettanto complessi, no, non esiste. Anche perché se fai codice autodocumentato dove minchia li metti i commenti?
Lavorando su progetti grossi (milioni di righe) ho sempre trovato altrove i problemi di comprensione.
Vero, come detto non è l'if o il ternario il grosso problema di comprensione. Ma per i motivi di cui sopra, è altamente sconsigliato. E non solo da me...
Ultima questione, scrivere per agevolare chi ti deve aiutare.
Verissimo.
Se si chiede aiuto sarebbe buona norma rendere il compito dei volenterosi più facile possibile.
Ma essendo la scrittura un fatto soggettivo, io non saprei a monte come scrivere un codice per incontrare le abitudini di chi leggerà.
Si ma non è che ti si stia dicendo di "seguire le abitudini di chi leggerà", ma di "seguire le norme consuete di programmazione", qui sei tu ad avere una "abitudine" diversa dalla stragrande maggioranza degli sviluppatori. Se vuoi un aiuto devi scrivere codice comprensibile, se io devo metterci un'ora per capire cosa minchia fa il tuo listato, dopo 5 minuti lascio perdere, visto che non mi paga neanche nessuno...
Poi, fai come ti pare, tanto non lavori per me ed io non credo che avrò modo di analizzare un tuo codice
docdoc:
Mi viene il sospetto che tu non abbia mai realmente lavorato in un team di sviluppo
Secondo me abbiamo avuto esperienze molto differenti.
Non ho mai lavorato in team dove uno debugga il codice dell'altro.
I problemi che ho dovuto affrontare sono sempre stati ad un livello differente.
E quando siamo scesi al debug spicciolo, come è scritto il codice non è mai stato un grosso problema.
Mi rendo però conto che la mia esperienza possa essere parecchio diversa da quella consueta.
Hai fatto bene a farmelo notare.
Anche perchè qui siamo fuori dal mio ambito consueto di lavoro. Sto giocando fuori casa e quindi potrei dare opinioni un po' inconsuete.
maubarzi:
Secondo me abbiamo avuto esperienze molto differenti.
Non ho mai lavorato in team dove uno debugga il codice dell'altro.
Eh ma infatti "lavorare in team" significa che il gruppo deve essere intercambiabile. Quindi di fatto hai sempre programmato solo "per te", ecco perché ti trovi bene, ti capisco, anche io agli inizi facendo il freelance il codice dei miei programmi lo scrivevo "per me", visto che una volta funzionante consegnavo solo gli eseguibili al cliente/committente. Quindi avrei potuto fare tutto quello che mi pareva nel codice, l'importante è che funzionasse ovviamente.
Ma una forma mentale predisposta al lavoro in team consente di ampliare certi orizzonti, anche lavorativamente parlando, e non restare a fare l'"eremita"
Per cui ti consiglio comunque, anche se dovessi programmare per te stesso, di cercare di scrivere codice "leggibile" da un'altra persona (purché dotata ovviamente almeno di parli esperienza nella programmazione), non solo evitando codice criptico ma anche abbondando di commenti, tutte cose che aiuteranno anche te se dovessi riprendere in mano un progetto dopo mesi o anni. Ed una volta abituato a fare le cose in questo modo, sarà molto facile continuare a farlo.
Ciao!
[OT]
PS: per dire, vari anni fa ero appassionato di "Core War", un gioco inventato su Scientific American e ripreso da Le Scienze, in cui due programmi si sfidano in un'arena virtuale, e lì fare un codice più compatto significa la differenza tra la "vita" e la "morte" del tuo programma perché un codice più esteso non solo girerà più lentamente ma sarà più vulnerabile alle "bombe" dell'avversario. Tanto per parlare, il programma Core Wars più breve possibile si chiama IMP ed è composto da una sola istruzione: "MOV 0,1" che significa "copia il contenuto della cella corrente -indirizzo relativo 0- nella successiva". Quindi si "auto-replica" in avanti ed è difficilissimo da sconfiggere perché va colpita l'istruzione successiva prima che venga eseguita. Come contropartita, è talmente semplice che non potrà mai vincere.
Ah, ovviamente a suo tempo realizzai in C un assembler Red Code (il linguaggio usato) ed un MARS ossia una sorta di "macchina virtuale", l'arena dove si scontrano i programmi...
[/OT]
Stiamo dicendo entrambi più o meno le stesse cose ma dando pesi diversi alle varie questioni.
Io non lavoro da solo ma semplicemente con altri professionisti di profilo uguale o superiore al mio dove i problemi non sono mai dovuti a inesperienze o a sviste o a errori di mera scrittura di codice, ma in genere sono più "concettuali".
Quindi si ragiona molto di più sulla "carta" che sul "codice scritto".
Le cose di cui si parla in questa discussione, forse, le diamo un po' per scontate e ci vengono naturali senza tanto stabilire regole a monte.
Le regole ci sono e sono circa le stesse che magari usi tu, solo che noi le applichiamo già a buon senso senza che ci sia qualcuno che le imponga o le formalizzi, per questo io forse minimizzo su questo aspetto ritenendolo meno importante, perchè per me è già risolto a monte.
Questa mia esperienza, mi rendo conto, non sia la norma.
Però non facciamo passare il messaggio che stiamo dicendo cose diametralmente opposte, ad un certo punto tu scrivi:
docdoc:
Non è "centrale" ovviamente ma neanche "marginale"
Semplicemente stiamo collocando la questione in due punti intermedi leggermente differenti.
EDIT:
Riguardo il tuo OT, dovevate farla in PERL la sfida, li si che si riescono a scrivere codici molto potenti ma altrettanto criptici.
fabpolli:
seguendo le regole del Barr group ho cambiato stile e devo dire che per me è diventato più leggibile il codice con le graffe isolate nella loro riga e se non erro anche le MISRA lo impongono
Ho buttato un occhio sul Barr Group, che si dichiara armonizzato con le MISRA.
Anche se non mi piacciono tante righe vuote formate da sole graffe, concordo sul fatto che risulta più leggibile a colpo d'occhio, non c'è da "decodificare" niente, le coppie di graffe formano in modo naturale dei "portoni" con dentro i blocchi di codice, e la leggibilità è buona solo indentando di almeno quattro spazi.
Vedo che il continue è sconsigliato, che il goto non è categoricamente vietato (ma va usato come ultima spiaggia solo in casi realmente eccezionali).
Ma, non so se l'ho perso, non vedo accenni riguardo l'uso deprecabile del ternario...