Linguaggio arduino

[franx]

Sarebbe buona norma (come è scritto sul K & R) usare lettere esclusivamente minuscole per le variabili e lettere esclusivamente maiuscole per le etichette simboliche.

Quindi:

Codice: Seleziona tutto

int pin_ir = 1;

oppure

Codice: Seleziona tutto

#define PIN_IR  1

[fairyvilje]

Questa è e rimane una scelta prettamente stilistica e non funzionale, tanto più che il preprocessore sta scomparendo e la necessità di nominare costanti e macro in questo modo decade. Conosco molte persone che direbbero così, tuttavia per la leggibilità del codice vedere subito i nomi delle variabili in maiuscolo a volte aiuta notevolmente in mezzo ad una districata confusione di strutture, classi e funzioni. Altrimenti bisognerebbe considerare pure le infinite tipologie di notazione per i nomi, e decidere la migliore non porterebbe a niente ;)

[Paolino]

Questa è e rimane una scelta prettamente stilistica e non funzionale...

Beh, su questo punto ci sarebbe da disquisire parecchio (e in parte, su queste pagine, ne abbiamo parlato, anche se solo in cenni). Esistono realtà merceologiche, come ad esempio l'automotive, dove è richiesto per il settore embedded un certo stile nella scrittura dei codici sorgenti, stile che è tanto di natura funzionale quanto di natura stilistica.

Per quali motivi? Eccoli, esposti in breve.

Aspetto funzionale.
Il linguaggio C è certamente uno standard, se si considera ANSI-C ad esempio. Ma come sappiamo esistono sfumature che sono specifiche degli ambienti di sviluppo nei quali si opera. Se allo sviluppatore si concede l'uso indiscriminato del C, magari con puntatori a strutture o union o quant'altro si voglia, in taluni casi potrebbe portare ad una instabilità del codice, con il rischio di avere dei comportamenti inattesi come restart del micro o altro ancora.

Aspetto stilistico.
Non so quanti sono abituati a lavorare in team o a dover condividere librerie e codice sorgente da riutilizzare. Avere un unico stile nel rappresentare i nomi delle variabili, strutture, funzioni, costanti, ecc., permette a tutti gli appartenenti al gruppo di ridurre i tempi di lettura del codice svolto da altri.

Si potrebbe continuare, magari ci faccio un articolo.

Ciao.

Paolo.

[Ianero]

Io invece sono più d'accordo con franx, uso la stessa convenzione anch'io e mi trovo bene, poi spetta al programmatore organizzarsi nel miglior modo il suo codice.

[0206pippo]

grazie a tutti davvero!!ho le idee chiarissime ora..:)

[fairyvilje]

Questa è e rimane una scelta prettamente stilistica e non funzionale...

Beh, su questo punto ci sarebbe da disquisire parecchio (e in parte, su queste pagine, ne abbiamo parlato, anche se solo in cenni). Esistono realtà merceologiche, come ad esempio l'automotive, dove è richiesto per il settore embedded un certo stile nella scrittura dei codici sorgenti, stile che è tanto di natura funzionale quanto di natura stilistica.

Ammetto la mia ignoranza non conosco queste realtà. Se non altro spesso si ha a che fare con linguaggi C-like e non ANSI C.

Se allo sviluppatore si concede l'uso indiscriminato del C, magari con puntatori a strutture o union o quant'altro si voglia, in taluni casi potrebbe portare ad una instabilità del codice, con il rischio di avere dei comportamenti inattesi come restart del micro o altro ancora.

I puntatori a strutture sarebbero uso indiscriminato? E le unioni po? Sono una delle basi costruttive del linguaggio. Ti sfido a progettare un sistema operativo od un driver senza l'uso di puntatori a tipi definiti dal programmatore. Impossibile. E' chiaro che uno deve sapere cosa sta facendo. Con dei puntatori si possono combinare parecchi casini concordo, ma di per se non devono essere una caratteristica instabile in una implementazione del linguaggio C.

Aspetto stilistico.
Non so quanti sono abituati a lavorare in team o a dover condividere librerie e codice sorgente da riutilizzare. Avere un unico stile nel rappresentare i nomi delle variabili, strutture, funzioni, costanti, ecc., permette a tutti gli appartenenti al gruppo di ridurre i tempi di lettura del codice svolto da altri.

Su questo punto infatti non posso che darti ragione. Dipende appunto da come un progetto ha deciso di rappresentare i nomi :). Il tuo proposto è UN modo non IL modo. E' molto utilizzato dalle persone perché "tramandato" dagli albori del C, ma riflette solo una delle molte possibilità per scrivere codice (comprensibile).
Non voglio aprire un offtopic su questo punto perché alla fine non serve molto, ma una descrizione delle principali convenzioni di scrittura potrebbe essere utile. Sarei felice di leggere il tuo articolo.

PS. Anche io uso la stessa convenzione di solito, e penso che un buon 90% dei programmatori C/C++ fa riferimento a questa. Il fatto è che se utile per la chiarezza del codice e per vedere immediatamente le variabili più importanti in un algoritmo complesso, perché non scriverle in maiuscolo?

[Paolino]

L'uso di strutture e puntatori non è di per sé un uso indiscriminato. Lo diventa quando, per realtà embedded, le strutture dati vengono costruite in modo "creativo" quando magari si potrebbe fare qualcosa di più semplice. Quando si è su un progetto non didattico, credo che un po' di pragmatismo sia la cosa principale. E, sotto questo aspetto, si preferiscono strutture semplificate (laddove possibile, certo) piuttosto che validi esercizi accademici che possono diventare trappole mortali per il micro. Un altro aspetto che non ho citato è la manutenibilità del software: chi svolge questa funzione? Il progettista o una terza persona? Mi è capitato di essere "il terzo" e di aver incontrato non poche difficoltà nell'interpretazione di un codice (assembly) scritto da un altro.

Il tuo proposto è UN modo non IL modo. E' molto utilizzato dalle persone perché "tramandato" dagli albori del C, ma riflette solo una delle molte possibilità per scrivere codice (comprensibile).

Se entri in un gruppo che segue certe norme/convenzioni per la stesura del codice, ti devi adeguare, non puoi imporre. Puoi proporre, certo. Ma ripeto: in alcuni casi, si seguono standardizzazioni fatte da Enti/Associazioni e ci si adegua. Spesso il cliente vuole che il tuo codice sia "compliant" con tali norme/convenzioni. E viene egli stesso a verificare!

Un aneddoto.
Mi sono trovato, circa 6 anni fa, a sviluppare codice C con altre persone che utilizzavano la "notazione ungherese" unitamente al Camel Case. Questa modalità a me è piaciuta, l'ho adottata subito! Da allora, un mio ipotetico codice ha le variabili scritte in questo modo:

Codice: Seleziona tutto

unsigned char uchSetPoint;
unsigned int uiIntegralTime;

char chSingleValue;



Ora, a distanza di tempo, mi ritrovo in un'altra realtà professionale ove il Camel Case è vincolato a ben precise regole mentre la notazione ungherese è bandita. Motivo? Adeguamento ad uno standard. Pertanto, io che am(av)o molto scrivere in quel modo, mi devo pian piano adeguare e cercare quanto prima di uniformarmi per evitare di scrivere in un modo non accettato dai miei colleghi. E i miei colleghi sono anche oltre oceano...

Ciao.

Paolo.

[TardoFreak]

... Il tuo proposto è UN modo non IL modo. E' molto utilizzato dalle persone perché "tramandato" dagli albori del C, ma riflette solo una delle molte possibilità per scrivere codice (comprensibile)...

No, è IL modo.
Questo perché una delle caratteristiche più importanti di un programma, insieme ad affidabilità e robustezza, è la manutenibilità. Questo sta a significare che fino a quando ti fai i programmi per te puoi anche scrivere le cose alla cavolo (ognuno è libero di scegliersi la morte che preferisce), quando li devi scrivere per qualcuno invece DEVI usare queste convenzioni.
Se dessi da scrivere un sorgente ed il programmatore mi mettesse le variabili in maiuscolo e le macro in minuscolo, o riscrive il programma, o i soldi se li sogna perché tale programma non sarebbe manutenibile.

Una piccola nota: il preprocessore non è affatto in disuso, fidati di me. Oppure non ti fidare e prova a vedere come sono scritti i programmi e le librerie di qualsiasi produttore di micro.

[Paolino]

TardoFreak, abbiamo espresso lo stesso concetto

Ciao.

Paolo.

[TardoFreak]

Si, in effetti ci siamo sovrapposti ma tant' è.

Edit: io comunque uso il Camel Case ed ho preso anche l' abitudine di indicare sempre short o long per gli interi (perché con i 32 bit che uso io il default di int è long int) e signed o unsigned sui char perché molti compilatori tendono a considerarli unsigned per default.