Conciso Vs Barocco Vs Bizantino

Queste sono solo considerazioni, non ho una domanda
anzi no, una sì: parliamone, scambiamo punti di vista
A mia idea il grande pregio del C è la sua concisione
Alcune cose sono scelte ben precise che risalgono alla AT&T e ai Bell Labs
HIGH e true sono solo e sottolineo solo delle scorciatoie (HIGH poi è pure un macro) per indicare 1
stessa cosa per LOW e false
per definizione, e per precisa scelta negli anni 60, non serve fare un test == HIGH
se questa cosa non è chiara non si è capito lo spirito del C
di recente ho visto alcune cose che stanno tra il Barocco e il Bizantino
una cosa così è deleteria da vedere, scrivere e capire:

bool rilevoMovimento(int pir) {
  int pirVal = digitalRead(pir);
  return (pirVal == HIGH);
}

tralascio altri commenti sull'intero argomento dal quale go tratto il frammento di codice, che sarebbere al vetriolo, ma non sono argomento di questo topic
dicevo, questo frammento di codice è come minimo barocco se non puro bizantinismo:
se chiama una funzione che usa una variabile (oltretutto inutilmente grande) locale per conservare un risultato che viene usato solo una volta per restituire un test inutile

bool rilevomovimento(int pir){
return digitalread(pir);
}

fa lo stesso lavoro senza un test inutile e senza usare una variabile locale
ma si vede bene che una funzione di una sola riga è a sua volte inutile, si scrive la riga direttamente
funzione che a sua volta è usata in una sola riga di un ciclo...
questo NON è un esempio di come programmare in C
Chi, da inesperto legge queste righe, NON capisce lo spirito del C e poi combina cose come quelle che si vedono nel topic dal quel ho estratto il frammento
se vogliamo aiutare è cosa positiva, ma da aiutare a indicare strade che sono contrarie allo spirito del C ne passa tanta di acqua sotto i ponti
nessuno me ne voglia per queste mie parole, l'insonnia ha guidato la mia tastiera, vogliono solo essere spunto per una discussione, magari ne escono linee guida che possono essere di aiuto anche a me
sopratutto evitiamo di dire che tutto questo è fatto permigliorare la leggibilità: non è vero, e comunque nello stesso topic si trovano costrutti FOR e IF senza le parentesi graffe,

for (int i = 0; i < NUMPIR; i++)
    if (rilevoMovimento(pirPin[i]) )
        attivoLuce();
        delay(500);

che leggibilità ci sarebbe in questo?
la if fa parte del for o no?
la attivoluce viene eseguita dalla if o dal for?
la delay è dentro nel for?
oltretutto i rientri sono sbagliati
Questo non è nemmeno un modo di programmazione bizantino, è proprio ermetico
difficile da comprendere e poi in futuro da mantenere

Credo che la funzione meno usata dell'IDE sia quella "formattazione automatica" che si trova nel menù stumenti.
Penso che molti credano che essa serva a cancellare automaticamente la memoria di Arduino al caricamento di ogni sketch.

Niente, le faccine non mi escono
Purtroppo temo tu abbia ragione

Standardoil:
Queste sono solo considerazioni, non ho una domanda
anzi no, una sì: parliamone, scambiamo punti di vista

Standardoil, comprendo benissimo ciò che dici e sono anche d'accordo (da "vecchio" programmatore che ha iniziato a studiare C sul K&R), ma tu da grande mi sa che devi fare il politico, perché hai preso degli esempi "decontestualizzandoli" totalmente per dimostrare qualcosa con uno scopo diverso.

Quegli spezzoni di codice li hai presi da una cosa che IO ho scritto AL VOLO (e meno male che l'ho pure detto che l'avevo scritto su sue piedi...) per un utente evidentemente inesperto e che non aveva capito bene alcune cose, e per far capire a qualcuno come dare una "strutturata" al suo codice che ho solo leggermente ritoccato e riassemblato in funzioni, e che LUI avrebbe dovuto verificare. E per iniziare a fargli prendere coscienza, anche debuggare. Ed anche questo era stato scritto esplicitamente.

Per cui senza polemica, ovviamente, mi sei anche simpatico e quando leggo certi subject diciamo "diversi dal normale" spesso capisco che sei tu l'autore e l'apprezzo molto anche perché spezza la noia di certi post, però scusa se te lo dico, non ti mettere a fare il "language nazi", ok?...

Anche tu mi sei simpatico.
E hai ragione che lo hai scritto al volo, lo ho volutamente decontestualizzato
Io personalmente ho imparato anche da te, è colgo l'occasione per ringraziarti.
Però leggere quelle righe mi fa una strana sensazione. E quello OP ha già qualche problema a imparare,
Nel complesso il cocktail è sbagliato, non so se mi spiego, temo di no, ma assolutamente non è una critica, semmai un segnale di non trovo la parola. Tipo malessere indotto in me
Ah, inoltre, grazie per i complimenti

Ah, è poi questo merita un post separato. Non un Edit:
Ho solo preso quel codice come esempio, perché era lì a pochi click di distanza, ma qui è pieno di esempi del genere.

Si, certo, concordo, ma se l'OP scrive 20 righe di codice tutte "strane" perché non ha esperienza di programmazione, non lo si può sommergere di considerazioni e questioni di stile, altrimenti per bene che vada, non ci capirà molto o si confonderà ancora di più le idee, se va male invece si demoralizzerà ritenendo una cosa troppo complicata da capire e magari abbandonerà il progetto.

Invece andando per gradi, limitando a una "rivisitazione" del suo codice, ed inducendo anche qualche errorino (uno era voluto, un altro è un mio errore, le graffe su cellulare sono complicate da scrivere e mi sono sfuggite;) ) tanto per fargli "assaggiare" come capire gli errori di compilazione e soprattutto correggerli, lo ritengo il modo migliore per guidare qualcuno a capire meglio ciò che sta facendo.

Al di là delle ottimizzazioni o delle raffinatezze stilistiche, prima deve imparare a scrivere almeno funzioni corrispondenti a blocchi logici, poi potrà fare i successivi passi. Come dire, prima di imparare a guidare deve almeno conoscere le regole del Codice della Strada, poi potrà apprendere la guida veloce, no?..

PS: a proposito dei vari "stili" di programmazione, non so se hai mai partecipato (o visto) qualche contest di codice C "compatto" ossia scrivere lo stesso programma ma in modo più compatto possibile (o con meno righe sorgente o che generi un binario più piccolo): in C si possono fare codici piccolissimi ed efficientissimi ma assolutamente illeggibili..

PS2: visto che chiacchieriamo, e per farti capire il mio background, io "ho una certa età", ed a suo tempo partecipai anche ai vari tornei di Core Wars di MC Microcomputer con Corrado Giustozzi, e ne ho anche io stesso organizzato un paio sulla mia BBS (parliamo di primi anni '90!): se sai di cosa parlo capisci anche che in quel caso (anche se era un linguaggio praticamente assembler) efficienza e compattezza erano i principi base di un buon combattente CW. Per dire, il più compatto e difficile da distruggere era l'IMP, costituito da una sola istruzione "MOV 0,1"...

Standardoil:
...omissis

for (int i = 0; i < NUMPIR; i++)

if (rilevoMovimento(pirPin[i]) )
       attivoLuce();
       delay(500);

...omissis

oltretutto i rientri sono sbagliati
Questo non è nemmeno un modo di programmazione bizantino, è proprio ermetico
difficile da comprendere e poi in futuro da mantenere

non me ne volere....
perchè i rientri sono sbagliati, quali dovrebbero essere?
cioè.... se lo scrivo con le graffe mi sembra che siano giusti.... senza non ne ho idea

per il discorso in generale hai perfettamente ragione, bisognerà proporre che alla compilazione venga aggiunta la formattazione automatica del codice

Patrick_M:
perchè i rientri sono sbagliati, quali dovrebbero essere?

Il delay() è fuori posto

for (int i = 0; i < NUMPIR; i++)
    if (rilevoMovimento(pirPin[i]) )
        attivoLuce();
delay(500);

Il FOR è seguito dalla IF che ha la sua condizione TRUE ... e termina li.

Tanto vale scriverlo ...

for (int i = 0; i < NUMPIR; i++) if (rilevoMovimento(pirPin[i]) ) attivoLuce();
delay(500);

Se invece il delay() doveva essere eseguito ad ogni esecuzione del IF ... allora ci vogliono le parentesi ...

for (int i = 0; i < NUMPIR; i++)
    if (rilevoMovimento(pirPin[i]) ) {
        attivoLuce();
        delay(500);
    }

Guglielmo

Non te ne voglio.
Ti spiego:
Senza le graffe il for esegue una sola riga: la if
A sua volta senza le graffe la if se esegue esegue solo un riga, la attivoluce
Quindi la delay non è "figlia" ne della if ne del for, pertanto non va rientrata.
Io consiglio, basta che guardi la mia firma, di mettere sempre le graffe, anche se per una riga sola, evita ambiguità
Ci siamo incrociati, con Guglielmo

Patrick_M:
non me ne volere....
perchè i rientri sono sbagliati, quali dovrebbero essere?

I rientri dipendono da qual è la logica dietro al codice, ossia cosa dipende da cosa, e soprattutto qual è lo scopo.
In quel caso l'unico problema è nel rientro della delay():

• for (int i = 0; i < NUMPIR; i++)*
• if (rilevoMovimento(pirPin[ i ]) )*
• attivoLuce();*
• delay(500);*

Quindi ti rispondo citando le giuste (o quasi ) obiezioni di Standardoil per farti capire cosa intendeva lui:

"la if fa parte del for o no?" Certo che ne fa parte, non essendoci graffa è l'unica istruzione presente nella for().
"la attivoluce viene eseguita dalla if o dal for?" con la graffa mancante, si, dalla if()
"la delay è dentro nel for?" in questo caso no, non essendoci graffe la delay() è eseguita dopo la for().

E, per finire, sappi che ci sono due scuole di pensiero nel C, quelli che scrivono la graffa a fine riga

if ( test ) {

• // blocco*
  }

e quelli che la scrivono a capo:

if ( test )
{

• // blocco*
  }

Sono in pratica i Montecchi e Capuleti del C. Scegli quello che ti piace di più e mi raccomando, se scegli i Montecchi non rompere gli zebedei ai Capuleti (o viceversa).

per il discorso in generale hai perfettamente ragione, bisognerà proporre che alla compilazione venga aggiunta la formattazione automatica del codice

Non credo ci sia nessun IDE che forzi la formattazione automatica.
Ma nel dubbio, premere Ctrl-T non è tutta sta fatica..

Standardoil:
Io consiglio, basta che guardi la mia firma, di mettere sempre le graffe, anche se per una riga sola, evita ambiguità

Aaah ora capisco tutto. Sei un Montecchi.
Se si indenta bene (e IO nell'IDE, o anche in Notepad++ che uso spesso, lo faccio SEMPRE), non c'è bisogno della graffa per singole istruzioni.

Certo che sono un montecchi, di Montecchio maggiore, per l'esattezza
In realtà non importa quale scuola di estetica si segua, importa capirne motivi, pregi e difetti. E seguirla!!!!!! Non bastano i punti esclamativi, aggiungine un paio di carriole.

La prima legge di Nelson, che sono io:
Fai le stesse cose sempre alla stessa maniera, quegli errori li hai già corretti.

Standardoil:
Non te ne voglio.
Ti spiego:
Senza le graffe il for esegue una sola riga: la if
A sua volta senza le graffe la if se esegue esegue solo un riga, la attivoluce
Quindi la delay non è "figlia" ne della if ne del for, pertanto non va rientrata.
Io consiglio, basta che guardi la mia firma, di mettere sempre le graffe, anche se per una riga sola, evita ambiguità
Ci siamo incrociati, con Guglielmo

mi era sfuggito il delay fuori posto.... sarà perche anch'io uso sempre le graffe a costo di essere pedante e quindi l'avevo considerato parte dell'if

docdoc:
...omissis

E, per finire, sappi che ci sono due scuole di pensiero nel C, quelli che scrivono la graffa a fine riga

if ( test ) {

• // blocco*
  }

e quelli che la scrivono a capo:

if ( test )
{

• // blocco*
  }

Sono in pratica i Montecchi e Capuleti del C. Scegli quello che ti piace di più e mi raccomando, se scegli i Montecchi non rompere gli zebedei ai Capuleti (o viceversa).

Non credo ci sia nessun IDE che forzi la formattazione automatica.
Ma nel dubbio, premere Ctrl-T non è tutta sta fatica..

in effetti preferisco la prima versione ma non ho mai "zebedato" i Capuleti

lo so che non esiste la formattazione automatica.... era una battuta
siccome la maggior parte non sa neppure che esiste la possibilità della formattazione
e tanto meno del Ctrl-T !!
se i'IDE prima di salvare e compilare lo sketch te lo formattasse.... chi poi deve leggerlo sarebbe avvantaggiato

tra l'altro.... c'ho messo un bel po a trovare come e dove modificare per fare in modo chi mi formattasse il codice come volevo io....

Cioè? Cosa intendi con "formattare come volevo io"?

Standardoil:
Ah, è poi questo merita un post separato. Non un Edit:
Ho solo preso quel codice come esempio, perché era lì a pochi click di distanza, ma qui è pieno di esempi del genere.

Si, vero, di codice così ce n'è a bizzeffe qui dentro ma capisco che è figlio di insegnamenti sbagliati, troppo prolissi, anche se perfettamente funzionanti e leggibilissimi.

Poi anche li si può aprire un dibattito: all'inizio l'esempio della variabile pirVal sarà leggibilissima, perfettamente attinente alla teoria, ma prolissa e inutile.
Poi con quel modo di scrivere ti trovi a programmare un PLC in Structured Text (molto ma molto conciso, ma molto molto veloce da scrivere) e ogni variabile che apri la devi duplicare nella Crosstable, riaggiornare tutto e ricordarti che ce l'hai, per poi capire che non serviva aprirla...

Io sono partito dal basso, addirittura dall'assembler e il Basic ci sembrava la risoluzione di tutti i problemi (i cicli for-next, le if-then-else e altre amenità partirono da li), ma i programmi si facevano con tre righe.
E vi giuro che ho sofferto moltissimo passare al C e al dichiarare le variabili "prima" e non "durante" (già la cosa era cominciata col Cobol... Ma perché? dicevo io).

Il primo Windows occupava qualche centinaio di mega, l'ultimo qualche decina di Giga: siete convinti che è tutto così necessario o, forse, noi tutti troveremmo da sfrondarlo qua e la?

Mi sono trovato a programmare centri di lavoro in ISO e con poche righe fai di tutto (certo, se vuoi fare una sfera devi programmare 24h per dei mesi ma questa è una eccezione), poi è arrivato il CAM che "interpreta" il tuo disegno e tira giù il programma ISO: 10 righe le mie, 65 righe le sue.
Per fare la stessa identica cosa. Con la stessa precisione !

Sono ancora convinto che ci sono ottimi programmatori che sanno coniugare rapidità e leggibilità, ed altri che sanno solo scrivere bene...

PaoloP:
Credo che la funzione meno usata dell'IDE sia quella "formattazione automatica" che si trova nel menù stumenti.
Penso che molti credano che essa serva a cancellare automaticamente la memoria di Arduino al caricamento di ogni sketch.

Questa mi fa ancora sbellicare dalle risate !!!!

docdoc:
Cioè? Cosa intendi con "formattare come volevo io"?

applicare le formattazioni che desideravo (spaziature, indentazione ...) nel file formatter.conf

Patrick_M:
... nel file formatter.conf

... lo trovate in arduino/lib ... copiatelo nella stessa cartella dove è il file "preferences.txt" e modificate la copia così ... NON viene cancellato ad ogni nuova versione dell'IDE

Guglielmo

si, si fatto