If innestati o AND?

[wizard]

Buongiorno,
grazie a tutti per le risposte anche se ad un certo punto siamo usciti fuori tema
è stato comunque istruttivo fare questo excursus.

... oltre ad affidarti a un valido compilatore, se proprio proprio ti vuoi togliere il dubbio, puoi andarti a leggere il listato in assembly ( maamemipiace scrivere "assembler") e contare i tempi d'esecuzione per ogni istruzione seguendo poi i possibili vari rami del flusso del programma se l'istruzione in causa diventa qualcosa di più articolato ... ma è un lavoraccio.

WALTERmwp, sì è un lavoraccio anche un po' da folle
In realtà la mia domanda (posta male, effettivamente) richiedeva una soluzione più banale in quanto voleva cercare di tirar fuori un modus operandi o al limite una guida da leggere per scegliere la strada migliore durante la scrittura del codice.

Buona domenica

[Sjuanez]

DarwinNE, ti ho invocato e sei passato a dare il tuo ottimo contributo. Ti ringrazio e sono d'accordo con te.

Sulla qualità del codice Open c'è stato, c'è e ci sarà ancora di più in futuro un dibattito sempre acceso.

Ho sempre pensato che condividere il codice e basta non è sufficiente per migliorare un progetto. Una persona che vuole contribuire o modificare qualcosa deve rileggerselo tutto ed è facile perdere il bandolo della matassa.

Pochi progetti hanno purtroppo una documentazione seria, dove si può indagare la ragione che ha portato a quelle scelte e intervenire. Fare reverse engineering, sbrogliare il codice di altri, anche se scritto bene, è comunque un'attività che impiega energie. Così come documentarlo per gli altri, è chiaro.

Su quanto detto da simo85, sono abbastanza d'accordo. Nel senso che, almeno fino a 5 anni fa, le capacità tecniche di chi contribuiva ai progetti open erano abbastanza elevate. E, come fatto giustamente notare da DarwinNE, non è nemmeno bastato, ma rimane un dato di fatto.

Da 5-6 anni a questa parte e penso ancor più in futuro, partecipare i progetti open è diventata un po una moda, una cosa da fare anche per tenersi allenati. Se sia un bene o un male, non so dirlo. Fatto sta che anche gente ai primi anni di università tira giù codice open e contributi, quindi non è più sicuramente un ambito "hacker" ma oserei dire quasi main stream.

Comunque è stato un bel thread, grazie a wizard per averlo aperto, scusa l'OT, e grazie a tutti per aver contribuito alla discussione.

[TardoFreak]

Piace ricordare che la stesura di codice è progettazione.
Come non si può progettare un circuito a mente, metterci una marea di componenti inutili ed affidarsi alla messa a punto per farlo funzionare, non si scrive codice alla carlona per poi passare il 90% del tempo a fare debugging per metterlo a punto.
Il codice va ragionato, pianificato ed infine scritto.
Non bisogna avere fratta di tempestare la tastiera, ma testa per progettarlo bene.
Alla fine s'impiega anche meno tempo e si scrive un qualcosa che ha senso dall'inizio alla fine.

[Sjuanez]

Il fatto è però che ci sono diversi livelli di approccio alla "progettazione". Non so per i circuti, ma per il codice puoi anche accontentarti di uno schema veloce su carta.

Mentre se vuoi fare le cose per bene, dovresti passare per:
-diagrammi dei casi d'uso
-diagrammi di classe
-diagrammi degli oggetti
-diagrammi di stato
-diagrammi di attività
-diagrammi di sequenza
-diagrammi di comunicazione

eccetera eccetera. e solo per citare l'UML.

Va da se che non sempre si può, e non è nemmeno consigliato, fare tutto questo. A volte una buona idea, uno schema su carta, il diagramma di classe, e via di codice. Non è ben progettato ma può bastare un'analisi agile del problema per cominciare a scrivere il codice se il software o la modifica è semplice e non ha necessità di essere condivisa.

Il punto, a mio avviso, è dare il giusto peso all'analisi preliminare e allo studio. Deve esserci sempre prima di mettersi a scrivere il codice, questo è ovvio, ma esagerare con la formalità può essere controproducente e antieconomico.

[TardoFreak]

Mi sono piegato male.
Non si tratta di abbondare in formalità ma di ragionare e calcolare prima di scrivere.
A volte apro i file di programmi che ho scritto 20-25 anni fa e mi metto le mani nei capelli (che intanto se ne sono andati).
Per carità, funzionavano alla perfezione, tuttavia ...

[Sjuanez]

completamente d'accordo e stessa sensazione!

[WALTERmwp]

(...) richiedeva una soluzione più banale in quanto voleva cercare di tirar fuori un modus operandi o al limite una guida da leggere per scegliere la strada migliore durante la scrittura del codice.

Un breviario vero e proprio non so se c'è e dovesse esserci non saprei quanto potrebbe essere d'aiuto.

Non è detto che leggibilità del sorgente ed efficienza del codice siano difficili da ottenere, ovvio scriverlo, ma dipende da chi ci mette le mani.
Che poi il connubio esprima pure una ottimizzazione è un altro discorso.
Il programma può "girare" molto bene benché siano state utilizzate enne variabili in più rispetto allo stretto necessario e non essere considerato come ottimizzato proprio per il ricorso a quelle variabili.
La soggettività riveste un ruolo talmente importante che l'esecuzione di un test multiplo può essere meglio se fatto in un modo piuttosto che in un altro.
Dipende proprio dalla persona.

Condivido col fatto che certamente delle regole di base ma anche di buon senso (pianificazione e impostazione) guidano alla stesura di un sorgente "ben fatto" oltre che, probabilmente, più abbordabile per un soggetto terzo ma, per quanto, è e resta sempre un programma scritto da altri.
Poi, tutto quello che viene riportato in un sorgente deve comunque essere coerente ivi compresi i commenti che, se non allineati al proposito dello statement riferito, possono addirittura essere fuorvianti e quindi addirittura dannosi.
Insomma, prendere in mano un programma scritto da altri, che sia per esempio in ambito gestionale piuttosto che un'applicazione d'automazione industriale è sempre, potenzialmente, un problema perché, mentre cerchi di capire quello "che fa" ti trovi con l'esigenza di "entrare nella testa" di quello che l'ha redatto.

Certamente i corretti propositi andrebbero sempre perseguiti quando si approccia un progetto software/firmware ma a volte non è proprio possibile, perché l'alternativa sta nell'alzare le mani: realtà di questo genere ne esistono e situazioni che ti portano a lavorare malissimo si verificano oggi più di ieri.

Nella impostazione e scrittura di un programma, l'aspetto più rilevante, dal mio punto di vista, sta nel conferirgli una struttura che in seguito permetta l'esecuzione di modifiche con interventi "puliti", che non conducano alla perdita di controllo: si dovrebbe cioè essere "sempre" in condizione di valutare con ragionevole certezza, e quindi prevedere, le conseguenze delle alterazioni apportate.
Che questa "predisposizione" la si raggiunga anche tramite un coerente uso delle variabili, dei loro nomi, piuttosto che di una indentazione "pulita" è un altro discorso, importante, ma è un altro discorso.

Con questo non vado ad aggiungere nulla di nuovo a quanto contengono gli altri Post(s), è solo il mio punto di vista ma la realtà o le realtà, nel momento in cui per vari motivi vieni coinvolto nella modifica di un sorgente altrui, sono più che varie come le relative criticità.

Saluti

[DarwinNE]

A volte apro i file di programmi che ho scritto 20-25 anni fa e mi metto le mani nei capelli (che intanto se ne sono andati).

Eh, ma quello succede un po' a tutti. Comunque, 25 anni fa non si scriveva codice come lo si fa adesso.
Io ricordo che una delle prime cose che ho scritto con l'assembly del C64 era una routinetta per pulire lo schermo in modalità grafica ed utilizzava del codice automodificante per andare un po' più in fretta

Comunque, è vero che si è andati un po' fuori argomento, ma se l'OP ha avuto le informazioni necessarie non vedo problemi a continuare perché comunque il discorso è molto interessante ed è comunque legato alla domanda iniziale che riguardava regole di buona scrittura del codice.

[TardoFreak]

Così, per fare qualcosa in una giornata di caldo terribile ...
Parlando di buona scrittura del codice prendiamo ad esempio la classica funzione per stampare una stringa.
25 anni fa l'avrei scritta così:

Codice: Seleziona tutto

void printString(char* s)
{
  char ch;
  // prende il primo carattere della stringa
  ch = *s;
  // esegue il ciclo fino a quando non incontra uno zero
  while(ch != 0)
  {
    // Stampa il carattere
    printChar(c);
    // Incrementa il puntatore al carattere
    s++;
    // prende il carattere successivo
    ch = *s;
  }
}

Che è il modo in cui si spiega a parole cosa deve fare la funzione. Tanti commenti inutili, codice buttato giù, funziona ma fa schifo.

Oggi lo scriverei così:

Codice: Seleziona tutto

void printString(char* s)
{
  while(*s) printChar(*s++);
}

Senza commenti perché non servono (il codice parla da se), senza variabili inutili, con le istruzioni necessarie e sufficienti.

[Sjuanez]

Tu comunque parli di 25 anni, a me capita anche con cose scritte 2 anni fa. Penso sia bello comunque e il segno che uno migliora in continuazione!

Il giorno che, vedendo una cosa che ho fatto in passato, non mi verrà in mente un modo per farla meglio...vorrà dire che ho smesso di migliorare.