Il vostro parere su due stili di programmazione

[c1b8]

Sono identiche al 99%, cambia solo lo stile di scrittura.

Non è vero. Scrivere:

Codice: Seleziona tutto

            mLED_1_Toggle();
            if(mGetLED_1())
            {
                mLED_2_On();
            }
            else
            {
                mLED_2_Off();
            }


o

Codice: Seleziona tutto

        mLED_1 = !mLED_1;
        mLED_2 = mLED_1;


ha lo stesso risultato, ma è completamente diverso.
Nel primo caso implementando le diverse funzioni posso cambiare il risultato, nel secondo caso devo riscrivere il codice principale. Se le funzioni fanno parte poi di una libreria si capisce come il primo metodo sia molto più faccilmente implementabile/espandibile del secondo.

[TardoFreak]

Intendevo in termini di tempo di esecuzione e di codice. Il secondo e' leggermente piu' compatto e veloce.
Ma la differenza, in questi termini, e' minima.

[posta10100]

sarei stato ancora più generico scrivendo una funzione che accende/spegne/inverte il led lasciando la decisione su QUALE led agire esterna alla funzione, passandole uno o più parametri.

Anche io generalizzerei il più possibile.
Forse sarebbe un pochino più lento ma sicuramente se dovessi modificarlo un domani sarebbe molto più semplice.
Se un domani dovessi utilizzare dei led più luminosi di quelli presenti oggi e volessi mantenere la luminosità attuale dovrei riscrivere mezzo programma per accenderli con il PWM, se avessi una funzione dedicata mi basterebbe modificare quella.
Riguardo i tempi di esecuzione non cambierebbe molto.
Se tu definissi la funzione

Codice: Seleziona tutto

int somma(int a, int b) {
  return a + b;
}
int d = 4;
int e = 3;
int c = somma(d, e);


come

Codice: Seleziona tutto

inline int somma(int a, int b) {
  return a + b;
}

int d = 4;
int e = 3;
int c = somma(d, e);


il compilatore andrebbe a sostituire in tutti i punti in cui la funzione viene chiamata il codice

Codice: Seleziona tutto

int c = d + e;


risparmiando tempo a discapito dello spazio utilizzato.

ho tentato di programmare
lo SCU in Java la funzione Fad_In e Fad-Out ed ho constatato
tempi di esecuzione impossibili !

Java è un discorso a parte.
La memoria viene gestita da un garbage collector che gira quando tutta la memoria è stata utilizzata alla ricerca di ciò che si può buttare. E questo fa perdere tempo.
Se devi ad esempio elaborare un file di alcuni GB e devi farlo in fretta allora la soluzione è scrivere la routine in C++, metterla in una libreria e richiamarla da Java.
In questo modo si ha la facilità di gestione di Java unita alla velocità del C++.

[TardoFreak]

Ritornando alla funzione.
Mettiamola cosi': in un programma vero, con funzioni complesse davvero, ha senso portarsi dietro 12 #define in piu' per implementare questa infima funzione nel primo modo?

[c1b8]

Secondo me si. Ti giro la domanda: quando sviluppi software non è preferibile farlo riutilizzando software già fatto? Se si questa funzione, oggi infima, domani potrebbe diventare (in altro sviluppo) simile ma molto importante, ma senza generalizzarla con le 12 define in più, potrebbe essere difficile riutilizzarla.
La domanda potrebbe quindi essere: conviene perdere tempo ora per utilizzare le 12 define o eventualmente implementarle dopo all'occorrenza? Secondo me la prima...

[TardoFreak]

Sul riutilizzo del codice sono d' accordo anch' io.
Personalmente una funzione del genere (che fa lampeggiare due LED) la riscrivo per intero, e con una sola #define ed una #ifdef #elif #endif in piu' mi scelgo la prima versione o la nuova versione.
Una funzione del genere non ha senso espanderla perche' utilizza un sistema per la frequenza di lampeggio che e' troppo legata alla velocita' della macchina ed al tempo che intercorre fra una chiamata e la successiva, quindi non e' generale proprio in partenza. Se cambi il clock cambia la frequenza di lampeggio, se nel il ciclo principale da cui viene chiamata (la macchina a stati) inserisci un' elaborazione in piu' cambia la frequenza di lampeggio. Piuttosto avrei lavorato sull' indipendenza da questi fattori piuttosto che sprecare simboli per sciocchezze.
Su funzioni serie, piu' complesse e che davvero possono diventare qualcosa, riutilizzo e generalizzo senza alcun dubbio, questo e' chiaro, su questa funzione specifica no.

pi, per carita', e' solo la mia opinione e vale quanto vale.

[posta10100]

pi, per carita', e' solo la mia opinione e vale quanto vale.

Vale un voto, come quella di tutti!

Personalmente una funzione del genere (che fa lampeggiare due LED) la riscrivo per intero, e con una sola #define ed una #ifdef #elif #endif in piu' mi scelgo la prima versione o la nuova versione.

Tanto vale farlo direttamente la prima volta.
Ti complichi un pochino la vita, la complichi al compilatore che deve poi ottimizzare per il caso specifico ma te la ritrovi pronta per il futuro.

Piuttosto avrei lavorato sull' indipendenza da questi fattori piuttosto che sprecare simboli per sciocchezze.

Infatti è quello che si dovrebbe sempre cercar di fare, ottenendo di fatto una libreria di funzioni da riutilizzare, anche in altri progetti.

[crestus]

Mah... io sono un po' scettico su questo argomento per la semplicità del pezzo di codice...

in questo caso non capisco perché complicarsi la vita con dei define quando introducono una cosa facilemente comprensibile dal codice come un cambio di stato. da pivello che sono mi sembra più sensato lasciare il codice pulito senza costringere a "imparare" 12 (non le ho contate mi fido di TardoFreak ) convenzioni per comprendere il codice per quanto comprensibili....quelle utili sono al massimo le "toggle" che potrebbero essere lasciate per il fatto che accorciano il codice e forse diventando più immediate.


Comprendo la concezione di un codice adattabile e riutilizzabile...ma dipende a quali livello stiamo parlando.... Sinceramente non trovo tutta questa fatica riscrivere quel pezzo di codice...ci metto più tempo ad andare a vedere dove ho messo il file che sicuramente conteneva le righe già scritte e utilizzare la stessa terminologia che non scriverle sul momento "al volo".
Se la faccenda si fa più complessa beh...il ragionamento si capovolge....

mio umilissimo parere....

[c1b8]

pi, per carita', e' solo la mia opinione e vale quanto vale.

Vale, vale. Eccome se vale!
La discussione mi pareva avesse più carattere teorico che pratico sulla singola, e sulla specifica, routine di lampeggio di 2 led. Come tale la stavo portando avanti utilizzando il codice fornito come esempio. Ma la mia opinione non cambia in funzione della complessità della routine da scrivere.
La mia opinione è che non si debba partire, quando si scrive software, da considerazioni legate all'hardware. O almeno non in un primo momento. Nell'esempio citato è chiaro che se si parte considerando frequenze di clock, tempi di esecuzione di "tutto il resto" del programma, ecc. ogni istruzione, in ogni parte del programma, deve essere fortemente pensata e pesata. Ma allora forse anche la scelta del linguaggio diventa determinante.
E' mia opinione che il software debba essere pensato come fine a se stesso e non finalizzato solo al quel specifico pezzo di ferro su cui dovrà poi girare.
Necessito di una routine per far lampeggiare due led? Scrivo questa routine senza, inizialmente, calarla nell'hardware specifico. Solo in fase di deploy finale, quando tutto il software è pronto e devo ottimizzarlo, allora posso pensare a quali accorgimenti adottare ad esempio per far variare la frequenza di lampeggio.
Spero di essere riuscito a far comprendere il mio punto di vista.
Non scrivo software per micro se non per mio scopo personale ed hobbystico ed è forse per questo che il mio punto di vista non è corretto, ma ad oggi non mi sono mai trovato a dover tornare su una routine ripensandola ogni volta solo perché cambiava qualche cosa nell'hardware.

[movlw]

Se chi legge questo intervento guarda prima il mio nik può farsi un'idea dell'argomento.

Perché usare una sintassi così complessa come quella richiesta dal C, quando queste cose (alternare lo stato di un pin) sono patria dell'assembler? Qui dove lavoro non verrebbe mai accettata una soluzione in C a questo tipo di esigenze. Ma non perché non corretta, solo perché non immediata.

Tra i due casi proposti da TardoFreak, io personalmente (ma credo anche tutti i colleghi con i quali divido il lavoro) preferirebbero la seconda. Questo perché è di più facile ed immediata comprensione. E per collegarmi a quanto detto prima, una coppia di bsf e bcf sarebbero ancora più comprensibili.

Anch'io vengo spesso preso dal "morbo del riutilizzo" pensando all'utopia di una smisurata libreria di codice riutilizzabile a piacimento, qualsiasi sia il clock, l'hardware, la necessità. Dopo 25 anni che scrivo software per microcontrollori (non per "tirarmela", ma per dare un'idea del numero di righe scritte), è stato ben poco il codice riutilizzato. Potrebbe dipendere dalla mia scarsa abilità nel pianificare le routine, ma forse è dovuto ad altro.

Ad esempio dal fatto che, a parità di funzione, un programma deve consumare poco, un altro deve essere veloce, un terzo deve essere compresso per questioni di memoria, un quarto... e così via. Alla fine, una routine generica non soddisfa nessuna necessità e fare un programma per micro composto da routine generiche, alla fine, produce un risultato mediocre.

Questo non significa che uno "spaghetti program" sia il lavoro migliore, anzi. Solo che personalmente non vedo la necessità del riutilizzo quanto quella della chiarezza e dell'immediatezza di comprensione da parte di chi ha scritto il codice (magari dopo qualche anno), ma anche da parte di terzi che si dovessero trovare nella necessità di metterci mano.

Se per accendere un led devo guardarmi decine di definizioni, magari nidificate... è certo che perdo il filo del discorso, mentre se in mezzo ad un programma mi trovo l'istruzione

bsf LED_PORT, RX_LED ; turn on RX LED

posso essere matematicamente sicuro che anche ET, venuto da un altro pianeta, non avrebbe alcuna difficoltà a comprenderne il significato. Resta ovvio che nel prossimo programma dovrò riscrivere tutto, ma se mettiamo sui due piatti della bilancia il tempo per scrivere una facile routine da zero e quello per verificare l'adattabilità di una ben più complessa al caso specifico, non so da che parte penderebbe l'ago.