AIUTO CON UN PROGRAMMA

Secondo il mio socio, secondo me, e anche secondo il barr_group citato da claudio, indentare in quella maniera è emendabile "proprio" perchè rende illeggibile il programma
citare per citare sono capace anch'io:
regola 3.3a Un solo statement per riga
regola 7.1e le variabili devono avere nome lunghi almeno 3 caratteri, anche i contatori dei cicli
e , rullo di tamburi, la regola più violata di tutte:
regola 1.3b le parentesi graffe aperte devono essere da sole su una riga all'inizio del blocco che aprono, le corrispondenti parentesi graffe chiuse devono essere da sole su una riga alla fine del blocco
Ora, io sono d'accordo che queste regole sono solo consigliate, ma citarne una, la più "nascosta", oltretutto citarla male, dopo aver disatteso tutte le altre non mi è sembrato bello, per nulla
Comunque, alla fine di tutto il pistolotto:
quel frammento di programma è "mal scritto", NON è un esempio di programmazione 'C'

Standardoil:
Secondo il mio socio, secondo me, e anche secondo il barr_group ....

Concordo al 100% su tutto quanto scritto d Standaroil; quel pezzo di codice è ... un ottimo esempio di come NON si devono scrivere i programmi. :grin:

Guglielmo

So benissimo che tutte le altre prescrizioni sono state violate, ma non so se scritto secondo esse sia davvero più leggibile, o meglio, comprensibile.

p1dn = 0;  // segnali impulsivi alla prima pressione
p2dn = 0;

if (mar)
{
    p1ena = 1; 
}
else if (pul1 & p1ena)
{ 
    p1dn = 1;  
    p1ena = 0; 
}
else
{
    // Nothing
}

if (mar)
{
    p2ena = 1; 
}
else if (pul2 & p2ena)
{ 
    p2dn = 1;  
    p2ena = 0; 
}
else
{
    // Nothing
}

if (mar)
{ 
    out1 = 0; 
}
else if (p1dn & led & !out2)
{ 
    out1 = 1; 
}
else
{
    // Nothing
}

if (mar) 
{ 
    out2 = 0; 
}
else if (p2dn & led & !out1) 
{ 
    out2 = 1; 
}
else
{
    // Nothing
}

if (p1dn & p2dn & led)
{ 
    out1 = 1;  
    out2 = 1; 
}

Secondo me a volte la concisione e gli allineamenti, purché riferiti a sezioni molto brevi, aiutano a non perdersi tra troppa "sintassi sparsa". Qui non c'è un grosso algoritmo strutturato, ma programmazione a basso livello (al di sotto restano solo le equazioni del ladder), ci sono quattro blocchetti funzionali molto piccoli e indipendenti che interagiscono tra loro tramite segnali (le variabili). Vedere ogni blocchetto in una piccola area rettangolare, formato da sezioni ben distinte e incolonnate (le condizioni, le azioni ecc) personalmente mi aiuta a non confondermi. Che stilisticamente non piaccia lo posso comprendere.

Scusa, ma seplificarlo e renderlo più leggibile (gli else vuoti si possono evitare del tutto, checché se ne dica) ?

p1dn = 0;  // segnali impulsivi alla prima pressione
p2dn = 0;

if (mar)
{
   p1ena = 1;
   p2ena = 1;
   out1  = 0;
   out2  = 0;
}
else
{
   if (pul1 & p1ena)
   { 
      p1dn = 1;  
      p1ena = 0; 
   }
   //
   if (pul2 & p2ena)
   { 
      p2dn = 1;  
      p2ena = 0; 
   }
   //
   if (p1dn & led & !out2)
   { 
      out1 = 1; 
   }
   //
   if (p2dn & led & !out1) 
   { 
      out2 = 1; 
   }
}

if (p1dn & p2dn & led)
{ 
    out1 = 1;  
    out2 = 1; 
}

Guglielmo

P.S.: ... sono partito dal tuo codice al post di sopra ... non so nenache cosa fa :smiley: :smiley: :smiley:

gpb01:
... gli else vuoti si possono evitare del tutto, checché se ne dica ...

Mi autoquoto per spiegare ...

Sia le MISRA C-2012, terza edizione Feb. 2019, rule 15.7, che il libro citato da Claudio-FF (libro che, se ben ricordate, sono stato il primo qui sul forum a consigliare), parlano di mettere sempre lo statemnt else solo nei casi di if ( ... ) .... else if ... e non nei casi di semplici di if in cui non c'è motivo di avere un else vuoto!

In pratica, citando appunto le MISRA C-2012:

A final else statement shall always be provided whenever an if statement is followed by a sequence of one or more else if constructs. The else statement shall contain at least either one side effect or a comment.

Per cui:

if ( flag_1 )
{
   action_1 ( );
}
else if ( flag_2 )
{ 
   action_2 ( );
}
/* Non-compliant */

... mentre occorre terminare con:

else
{
   ;   /* No action required - ; is optional */
}

Guglielmo

P.S.: il libro "Embedded C Coding Standard", al punto 8.2.d dice esattamente la stessa cosa .... "Any if statement with an else if clause shall end with an else clause.".

Beh, trasformiamo un problema in una opportunità: ne facciamo l'occasione per aprire un megatopic regole di stile?
Dove consigliamo come scrivere programmi in uno stile standard, condiviso da tutti noi?
E accompagnamo i neofiti a scrivere in una maniera che sia compatibile con esso
Da non doverci tutte le volte scontrare con programmi scritti con colla e forbici?

Orbene, vediamo SR ci riesco io, seguendo le regole del barrgroup

// inizializzazioni varie

void setup(){
// le varie pin mode


}


void loop(){
if(digitalRead(pulsante0))
{avvio=HIGH;
digitalWrite(lampada0,avvio);


}
if(digitalRead(pulsante1)){
if(avvio)
{// vince 1
digitalWrite(lampada1);
}
else
{// barava, vince 2
digitalWrite(lampada2);

stop();
}

E poi basta che col telefono non riesco

Scusa, ma le regole le hai lette per sapere come evitarle?
Perché seguirle non le hai seguite...

Edit:
Non avevo letto che eri da telefonino.
Lascia stare, scrivi con lo IDE, all'inizio (sei all'inizio, vero?) è già dura da PC, lascia stare tablet, furbofoni e compagnie belle,

Standardoil:
Beh, trasformiamo un problema in una opportunità: ne facciamo l'occasione per aprire un megatopic regole di stile?

Mah ... fare si può fare, ma credi serva a qualche cosa?

Gli utenti continueranno a fare come gli pare, continueranno a non indentare, a non usare la funzione di formattazione automatica che, a costo zero, gli mette a disposizione l'IDE, a non voler sentire la parolina "studiare" e .... chi più ne ha più ne metta ... :confused:

Guglielmo

Avrai notato che io quelli li martello...
È il mio passatempo durante le lunghe giornate di collaudo cicloconvertitori: martellare gli ignavi...

gpb01:
Scusa, ma seplificarlo e renderlo più leggibile

Leggibile nella sintassi, o comprensibile nella logica? Perché è vero che hai dato una struttura più "canonica" alla sintassi e alle condizioni, accorpando anche apparenti ridondanze, ma seguirne la logica dal punto di vista di interazione tra piccoli functional blocks del tutto indipendenti tra loro che interagiscono, diventa improbo :wink:

Claudio_FF:
Leggibile nella sintassi, o comprensibile nella logica?

E' ottimizzato in entrambe le cose e, fondamentale nei sistemi a microcontrollore, è estremamente più efficiente (sia a livello di compattezza del codice generato che di velocità di esecuzione, cose essenziali in tali ambienti).

Dimentica l'ambiente PLC e la programmazione LAD (... che vedo usi), qui sei nel mondo dei "microcontrollori" e la logica di programmazione è del tutto diversa.

Guglielmo

@Claudio_FF scusa, non pensavo che sparando il mio mortaretto (esprimevo il mio gusto personale con una battuta) avrei scatenato il fuoco incrociato dell'artiglieria pesante :wink:
Io in genere aborro le regole calate dall'alto come dogmi e mi baso sul buonsenso, che spesso è molto simile a tali regole, anch'esse basate sul buonsenso di altri, ma non ne faccio una questione di principio o capestro.
Trovo, però, più facile seguire un codice scritto come ha fatto Guglielmo, sebbene più dispersivo nello spazio a disposizione, piuttosto di quello scritto da te, anche se il tuo sfrutta meglio lo spazio per essere visibile tutto. Ma questa, da parte mia, è solo una questione di abitudine, credo.

Certamente abitudine conta
Ma c'è da fare una considerazione
Nei linguaggi interpretati come scrivo ha importanza fondamentale, dato che, ad esempio un lotto di righe vuote tra due statement rimarrà a ingombrare il programma per ogni singola esecuzione, e anche solo il tempo per saltare la riga viene speso
Invece qui abbiamo un compilatore (e anche un preprocessore) che 'ridisegnano' il nostro sorgenteè e poi lo compilano
Approfittiamone
Mettiamo i vari statement 'belli larghi comodi sulla loro poltrona', è inutile scrivere varii (eccecaxxp variO al plurale fa variI qualunque cosa dica il foxxuto correttore di Android)
dicevo è inutile scrivere più statement assieme per risparmiare una riga, rischiando di scordarsi che una if , (ad esempio) esegue comunque sempre solo il primo
O peggio non 'vedendo' che in fondo alla riga, ben oltre la colonna 80, fuori schermo da un pezzo, è rimasta una foxxuta graffa
Leggibilità è questo, e in 'C' la concisione è data dal linguaggio, non dal numero di ritorni a capo

maubarzi:
Io in genere aborro le regole calate dall'alto come dogmi e mi baso sul buonsenso ...

Fortunatamente, specie in certi ambienti (es. automotive) le regole esistono (es. MISRA C) e vanno rispettate, altrimenti ... il software che sviluppi NON viene accettato :slight_smile:

Dico fortunatamente perché sono regole dettate dall'esperienza e fatte per evitare, il più possibile errori che, in detti ambienti, sarebbero "fatali" !

Guglielmo

Si possono fare sondaggi qui sul forum?
Se sì apriamo un topic apposta e proponiamo e votiamo una serie di regole comuni e condivise, beninteso da usarsi solo con neofiti
Poi privatamente ognuno usa quello che vuole..

Standardoil:
Si possono fare sondaggi qui sul forum? ....

T'ho detto che se vuoi, in area Software, il thread lo puoi aprire (lo metto anche sticky), anche se, ripeto, purtroppo so già che da molti verrà beatamente ignorato ... :confused:

Guglielmo

Stasera, con calma (calma? Cosa che è?) provo...

gpb01:
Dico fortunatamente perché sono regole dettate dall'esperienza e fatte per evitare, il più possibile errori che, in detti ambienti, sarebbero "fatali" !

Ma certo, infatti il mio buonsenso, mi porta molto vicino a tali regole senza averle manco lette.
Però il mio odio verso le regole dogmatiche resta.
In questo caso sono quasi tutte condivise, quindi l'odio scema, paradossale odiare qualcosa che condividi finchè non ne vieni a conoscenza :wink: