[C] Dove mettete il * ?

[DanieleC88]

Piccola domanda: dove mettete l'asterisco nelle dichiarazioni del C(++)? Io lo metto staccato dai nomi (es.: "char * ciccio", non "char *ciccio"), perché, in fin dei conti, definisce un particolare tipo.
Diverso, naturalmente, il discorso del dereferencing, lì io uso "*dst++ = '\0'", tanto per fare un esempio.

[Poix81]

secondo me e' piu' chiaro scrivere cosi':
char *ciccio

ciao ciao

[Fenomeno85]

secondo imho molto + leggibile.

~§~ Sempre E Solo Lei ~§~

[VICIUS]

secondo me e' piu' chiaro scrivere cosi':
char *ciccio

ciao ciao
:mano:

ciao ;)

[Ubi-Wan]

secondo me e' piu' chiaro scrivere cosi':
char *ciccio

ciao ciao

Concordo, io ho sempre scritto così

[fek]

Piccola domanda: dove mettete l'asterisco nelle dichiarazioni del C(++)? Io lo metto staccato dai nomi (es.: "char * ciccio", non "char *ciccio"), perché, in fin dei conti, definisce un particolare tipo.
Diverso, naturalmente, il discorso del dereferencing, lì io uso "*dst++ = '\0'", tanto per fare un esempio.

L'asterisco e' parte integrante della definizione del tipo quindi va attaccato:

char* str;
char** strPointer;

La versione "char * str" ad una lettura veloce assomiglia ad una moltiplicazione e puo' portare confusione.

Non e' una questione di gusti, ma di leggibilita' del codice.

[RaouL_BennetH]

L'asterisco e' parte integrante della definizione del tipo quindi va attaccato:

char* str;
char** strPointer;

La versione "char * str" ad una lettura veloce assomiglia ad una moltiplicazione e puo' portare confusione.

Non e' una questione di gusti, ma di leggibilita' del codice.

Scusa la domanda forse scema (per te), ma questo tipo di 'notazione', sbaglio o è maggiormente utilizzata in C++?

Dato che in C invece, si legge sempre: char *str oppure char **strPunt.

Thx.

RaouL.

[fek]

Scusa la domanda forse scema (per te), ma questo tipo di 'notazione', sbaglio o è maggiormente utilizzata in C++?

Dato che in C invece, si legge sempre: char *str oppure char **strPunt.

Thx.

RaouL.

Non e' una domanda scema :)

Non credo che l'uso di una notazione o l'altra dipenda dal linguaggio, ho visto la notazione "errata" usata spesso anche in C++. Forse e' piu' facile incontrarla in C perche' il codice C e' di solito piu' vecchio e la notazione "corretta" e' solo recentemente diventata di uso comune.

Ad esempio e' consigliata Da Herb Sutter e Alexandrescu in "C++ Coding Standards".

Ti faccio un esempio del perche' e' preferibile la prima notazione. Spesso si usa indentare le dichiarazioni di variabili per rendere piu' facile la lettura:


char a;
int b;
char* str;


Con la prima notazione, con un semplice colpo d'occhio puoi capire il tipo di ogni variabile solo scorrendo la colonna di sinistra di tipi, mentre con la seconda notazione sei costretto anche a guardare il nome nella seconda colonna per capire il suo tipo. Sembra una cosa di poco conto, ma quando leggi decine di migliaia di righe di codice puo' fare la differenza.

[ilsensine]

L'asterisco e' parte integrante della definizione del tipo quindi va attaccato:

char* str;
char** strPointer;

No è specifico della variabile; ad es. per dichiarare due puntatori devi scrivere
char *a, *b;
mentre è scorretto
char* a, b;

[cionci]

No è specifico della variabile; ad es. per dichiarare due puntatori devi scrivere
char *a, *b;
mentre è scorretto
char* a, b;
:mano:

[fek]

No è specifico della variabile; ad es. per dichiarare due puntatori devi scrivere
char *a, *b;
mentre è scorretto
char* a, b;

Questa e' un'idiosincrasia del C, purtroppo ereditata anche dal C++.
Infatti tutti i coding standard (decenti) impongono di dichiarare sempre una sola variabile per tipo. I nuovi linguaggi lo impongono nella loro grammatica.

Da evitare:
char *a, *b;

Molto piu' leggibile:
char *a;
char *b;

L'asterisco e' logicamente parte del tipo della variabile, purtroppo il C non lo impone, e' cura del buon programmatore (o dei coding standard) imporselo.

[cionci]

Secondo me è assurdo imporre una dichiarazione per linea. Soprattutto quando le variabili cominciano ad essere tante diventa tutt'altro che leggibile...

[ilsensine]

Questa e' un'idiosincrasia del C, purtroppo ereditata anche dal C++.
Non ho detto che è bello a vedersi (neanche a me piace), ho solo detto che così è stato deciso...

[fek]

Secondo me è assurdo imporre una dichiarazione per linea. Soprattutto quando le variabili cominciano ad essere tante diventa tutt'altro che leggibile...

Io invece la trovo un'ottima idea, quando le variabili diventano tante e' comodissimo scorrerle indentate in due colonne come ho descritto e con un colpo d'occhio capire il loro tipo.

Cose tipo:
int a, *b, c, d*, *d, e

sono ad esempio indicate come "Coding Horrors" in "Code Complete 2".
Da 10 anni a questa parte dichiaro una sola variabile per tipo e non mi sono sorpreso piu' di tanto quando ho visto questo uso imposto nei Coding Standard di ogni azienda dove ho lavorato.

[fek]

Non ho detto che è bello a vedersi (neanche a me piace), ho solo detto che così è stato deciso...

Questo non lo ha messo in dubbio nessuno, infatti il topic non chiedeva lumi sulla grammatica del C, ma sulla notazione usata. E di queso io stavo parlando.

[DanieleC88]

L'asterisco e' parte integrante della definizione del tipo quindi va attaccato:

char* str;
char** strPointer;

La versione "char * str" ad una lettura veloce assomiglia ad una moltiplicazione e puo' portare confusione.

Non e' una questione di gusti, ma di leggibilita' del codice.
Purtroppo è una questione di gusti... io ho trovato molto (molto) spesso le dichiarazioni scritte in questo modo: "char *str;", ma sinceramente lo trovo confusionario, esteticamente sgradevole e, forse, sbagliato, anche visto quello che tu dici.
Io uso sempre l'asterisco staccato dal nome del tipo e dal nome della variabile: "char *<tab>nomevariabile;". A volte anche con tabulazioni multiple (uso tab di 2 spazi :D - non criticatemi, anche qui si tratta di gusti), per separare bene le due cose.
Per tornare all'asterisco, secondo me (parere personale di un povero autodidatta, sia ben chiaro) l'asterisco non va nemmeno attaccato al nome del tipo, perché, se non erro, si tratta di un qualificatore, che quindi è specifico di una particolare variabile. In fondo sono un po' indeciso anch'io su come usare l'asterisco, visto che sintatticamente è probabile che sia più corretta la forma di cionci, ilsensine, VICIUS, etc.

Per le dichiarazioni, anche io uso una sola dichiarazione per linea. E, ovviamente, questo a volte diventa scomodo se bisogna lavorare con parecchie variabile, quindi in alcuni casi dichiaro pù variabili per linea, ma non se queste sono puntatori, proprio per evitare gli orrori di cui ci hai fatto qualche esempio.

[DanieleC88]

[...] ma sinceramente lo trovo confusionario, esteticamente sgradevole e, forse, sbagliato, anche visto quello che tu dici.
[...]
In fondo sono un po' indeciso anch'io su come usare l'asterisco, visto che sintatticamente è probabile che sia più corretta la forma di cionci, ilsensine, VICIUS, etc.[...]
Ehm... mi sono contraddetto da solo! :D

...comincio ad avere le idee un po' confuse...

[Python]

01. Pointers and references
char* p = "flop";
char& c = *p;
-NOT-
char *p = "flop"; // wrong
char &c = *p; // wrong

Reason: In C++, definitions are mixed with executable code. Here,
p is being initialized, not *p. This is near-universal
practice among C++ programmers; it is normal for C hackers
to switch spontaneously as they gain experience.


credo sia quello che vi interessa.... l'ho letto in un txt trovato per caso mentre spulciavo un pò di documentazione su c/c++

[fek]

In fondo sono un po' indeciso anch'io su come usare l'asterisco, visto che sintatticamente è probabile che sia più corretta la forma di cionci, ilsensine, VICIUS, etc.

Sintatticamente sono corrette entrambe, e semanticamente sono equivalenti, altrimenti una delle due non compilerebbe :p

Riguardo al lasciare uno spazio prima dell'asterisco, qui e' come dici tu quasi una questione estetica; io per mantenere consistenza ed evitare di confondermi con l'operatore di moltiplicazione preferisco evitare lo spazio.

[DanieleC88]

Sintatticamente sono corrette entrambe, e semanticamente sono equivalenti, altrimenti una delle due non compilerebbe :p
Hmm... nn ci avevo pensato. :)
Inoltre, anche il messagio di Python toglie ogni dubbio: sarebbe meglio mettere il puntatore non distanziato dal tipo.

[anx721]

Dal punto di vista sintattico l'asterisco non fa parte della specifica del tipo, bensì della specifica del "declarator", che definisce il tipo di oggetto dichiarato in una dichiarazione C;

nella dichiarazione

int *a;

la specifica del tipo è solo int, mentre l'oggetto dichiarato è '*a'.

cosi in

int *a, b;

int è il tipo e i 2 oggetti dichiarati sono *a e b,

Il tutto secondo la grammatica di Kenighan e Ritche:


http://www.lysator.liu.se/c/ANSI-C-grammar-y.html#declaration

[DanieleC88]

Che macello! :D
Vabbe', alla fine basta che il compilatore capisca come usare il puntatore... Insomma, scrivere "char* a", "char * a", o "char *a" alla fine non ha alcuna grande differenza, se non sul piano della leggibilità.

[fek]

Che macello! :D
Vabbe', alla fine basta che il compilatore capisca come usare il puntatore... Insomma, scrivere "char* a", "char * a", o "char *a" alla fine non ha alcuna grande differenza, se non sul piano della leggibilità.

"Every fool can write code that a machine can understand, only good programmers can write code that a human can understand" - Martin Fowler.

Adoro questa frase :)

[DanieleC88]

Adoro questa frase :)
Bella, piace anche a me. :)

[RaouL_BennetH]

"Every fool can write code that a machine can understand, only good programmers can write code that a human can understand" - Martin Fowler.

Adoro questa frase :)

per Fek:

Io leggo sempre con molto piacere i tuoi post, sopratutto perchè insieme a tanti altri che partecipano a questo forum, contribuite con la vostra preparazione eccezionale a chiarire le idee ai 'giovani' come me che si affacciano al mondo della programmazione. So che sei una persona estremamente intelligente per cui spero che, la piccola provocazione che ti farò, ti diverta anzichè farti 'arrabbiare' :)

La domanda mia è: a che serve produrre un codice leggibile da altri, rinunciando magari ad un proprio modo 'sintattico', quando la maggior parte del codice prodotto, nel caso dei sistemi chiusi, non è destinato alla lettura di nessun altro?

Cioè, vorrei capire se la preoccupazione della leggibilità del codice sia più prerogativa di chi si muove nell'ambito open source, oppure sia realmente una regola da seguire a prescindere.

[cionci]

RaouL_BennetH: i progetti solitamente non si portano avanti da soli, ma all'interno di un team di sviluppo potrà succedere che il tuo codice venga letto da altri... Poi è chiaro che un team si deve dare una autoregolamentazione, altrimenti se uno dei programmatori esce dal team quel codice avrà grossi problemi di compresibilità per gli altri...

[fek]

La domanda mia è: a che serve produrre un codice leggibile da altri, rinunciando magari ad un proprio modo 'sintattico', quando la maggior parte del codice prodotto, nel caso dei sistemi chiusi, non è destinato alla lettura di nessun altro?

Farmi arrabbiare? E' una splendida domanda :)
Ci vorrebbero pagine e pagine per rispondere.

Una parte dei motivi te li ha dati cionci, io aggiungo che e' imperativo mantenere alta la leggibilita' e la qualita' del proprio codice anche quando si programma da soli, perche' la persona che molto probabilmente dovra' rileggere e capire il tuo codice sarai proprio tu. E tu non vuoi far perdere del tempo a te stesso vero?

Credo che la motivazione principale dietro a questa affermazione risieda nel fatto che il codice non si scrive una volta sola e poi non lo si tocca piu', ma viene costantemente aggiornato, modificato, ripulito, ritoccato, corretto, revisionato, mantenuto. La stessa riga di codice, prima di andare in produzione alla fine del progetto, verra' probabilmente scritta una volta e riguardata decine, magari alla ricerca di un bug. E la persona che dovra' mantenere quella riga del codice sarai spesso proprio tu. Quando stai cercando un bug oppure inserendo una nuova funzionalita' e magari hai tempo fino a ieri, l'ultima cosa che vuoi e' perdere ulteriore tempo a leggere il codice e capirlo.

Il codice deve essere leggibile, autoesplicativo, minimale, e rivelare immediatamente le sue intenzioni.
Ti faccio un esempio che puo' sembrare estremo, ma in realta' non lo e' affatto e detta una buona norma di programmazione:

Guarda questo codice (inventato in un linguaggio simil C#):


void AddItemToCollection(Array array)
{
AddItemAtTheEnd(array);

// increment the number of items
itemsInCollection += 1;
}


E' sufficientemente leggibile. Puo' essere migliorato? Si'.


void AddItemToCollection(Array array)
{
AddItemAtTheEnd(array);
IncrementNumberOfItems();
}


La seconda versione si legge quasi come se fosse inglese, il commento e' sparito perche' non e' piu' necessario, visto che il metodo spiega gia' che cosa sta facendo e il commento sarebbe una duplicazione di informazioni. Nella seconda versione il codice stesso rivela chiaramente le sue intenzioni ed e' autoesplicativo. La seconda versione e' piu' leggibile della prima, anche di poco, ma il mezzo secondo che guadagno a leggere e capire la seconda versione, moltiplicato per decine di migliaia di righe fara' la differenza fra finire il mio task in tempo oppure no.

Certo, qualcuno potrebbe obiettare che una chiamata a funzione spreca qualche ciclo di clock... che lo dica :)

[RaouL_BennetH]

grazie per le vostre risposte, ci tenevo e mi hanno chiarito le idee :)

Thx.

RaouL.

[DanieleC88]

Concordo con quanto detto da cionci e fek, e mi permetto di aggiungere che il codice deve essere ben leggibile innanzitutto per te stesso. Ad esempio, io avevo abbandonato da più di tre mesi lo sviluppo del mio "sistema operativo", ma quando l'ho ripreso, per fortuna, non ho avuto grandi difficoltà nel modificare il mio codice. Buoni commenti e sintassi chiara sono, per me, essenziali per riuscire a capire il mio stesso codice a distanza di tempo.

Ad esempio io scriverei:
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char * argv[])
{
int result;

/* Skip the first argument, containing the path to our program */
argc--;
argv++;
/* Process arguments */
result = handle_options(argc,argv);
if (result != 0)
{
fprintf(stderr, "Couldn't process the arguments.\n");
return EXIT_FAILURE;
}
/* Return with no error */
return EXIT_SUCCESS;
}

Piuttosto che:
int main(int argc, char * argv[])
{
int r;

r=hdlopts(--argc,++argv);
if (r != 0) return -1;
return 0;
}

E non fato caso al significato del codice. È solo un esempio! ;)

[fek]

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char * argv[])
{
int result;

/* Skip the first argument, containing the path to our program */
argc--;
argv++;
/* Process arguments */
result = handle_options(argc,argv);
if (result != 0)
{
fprintf(stderr, "Couldn't process the arguments.\n");
return EXIT_FAILURE;
}
/* Return with no error */
return EXIT_SUCCESS;
}


E si puo' sempre migliorare.
Prova cosi':

#include <stdlib.h>
#include <stdio.h>

// argv[0] contains the path to our program
void SkipFirstArgument(int* argc, char** argv[])
{
*argc -= 1;
*argv += 1;
}

int ProcessArguments(int argc, char * argv[])
{
int result;

result = handle_options(argc,argv);
if (result != 0)
{
fprintf(stderr, "Couldn't process the arguments.\n");
return EXIT_FAILURE;
}

return EXIT_SUCCESS;
}

int main(int argc, char * argv[])
{
SkipFirstArgument(&argc, &argv);

return ProcessArguments(argc, argv);
}


Nota questa riga in particolare:

/* Return with no error */
return EXIT_SUCCESS;

Il commento non fa altro che ripetere quello che il codice gia' indica chiaramente, c'e' un'ovvia duplicazione e le duplicazioni vanno eliminate al piu' presto:

return EXIT_SUCCESS;

Il che porta dritto al discorso sui coi commenti, la butto li': Quando senti il bisogno di commentare un pezzo di codice, riscrivilo di modo che sia piu' chiaro e non abbia piu' bisogno del commento.

Il codice non va commentato :)
O meglio non commentare mai quello che fa il codice, ma solo le assunzioni sulle precondizioni e postcondizioni che non puoi esprimere in codice.

Nota le differenze in questo commento:

// argv[0] contains the path to our program
void SkipFirstArgument(int* argc, char** argv[])

Non sto commentando che cosa fa il codice, ma l'assunzione sulla quale si basa il codice di quella funzione, ovvero il fatto che il primo argomento contiene il path del programma, perche' non ho alcun modo di esprimere questa assunzione in codice. Il nome del metodo poi comunica che questo primo argomento sara' saltato.

[DanieleC88]

E si puo' sempre migliorare.
...E meno male che l'avevo pure scritto: "è solo un esempio". ;)
Il codice non va commentato :)
Non sono del tutto d'accordo. A volte ci si può trovare di fronte a cose un po' disorientanti, non come il semplice codice che ho scritto prima. Lì i commenti possono aiutare a decifrare subito.
#define ischar(x) x >= 'a' && x <= 'z' ? x >= 'A' && x <= 'Z' ? 1 : 0 : 1
Non è subito chiaro. Però, pensandoci bene, il codice potrebbe essere anche più chiaro semplicmente scrivendolo in modo diverso.
#define ischar(x) x >= 'a' && x <= 'z' || x >= 'A' && x <= 'Z'
In fondo basta questo... :)
Oppure, per modificare un po' il codice di prima:
#define ischar(x) (x > 'a' && x < 'z') ? ((x > 'A' && x < 'Z') ? 1 : 0) : 1
Così le differenze sono già più evidenti.

[fek]

...E meno male che l'avevo pure scritto: "è solo un esempio". ;)

Ho solo approfittato del tuo esempio interessante per introdurre il discorso sui commenti ;)


Non sono del tutto d'accordo. A volte ci si può trovare di fronte a cose un po' disorientanti, non come il semplice codice che ho scritto prima. Lì i commenti possono aiutare a decifrare subito.

Come dice Kent Beck, i commenti sono spesso un deodorante per coprire i cattivi odori nel codice, ma piuttosto di usare un deodorante e' meglio pulire il codice e togliere il cattivo odore :)

Nel caso del tuo ultimo esempio:
#define ischar(x) (x > 'a' && x < 'z') ? ((x > 'A' && x < 'Z') ? 1 : 0) : 1

Sicuramente questo codice non e' chiarissimo, vediamo se questa versione aiuta:


bool isChar(x)
{
if (x >= 'a' && x <= 'z') return true;
if (x >= 'A' && x <= 'Z') return true;

return false;
}


Molto piu' leggibile vero? Possiamo ancora migliorarlo, volendo:


bool isUpperCaseChar(char ch)
{
return ch >= 'A' && ch <= 'Z';
}

bool isLowerCaseChar(char ch)
{
return ch >= 'a' && ch <= 'z';
}

bool isChar(char ch)
{
if (isUpperCaseChar(ch) || isLowerCaseChar(ch))
return true;
else
return false;
}


Guarda che miglioramento ora, il codice rivela chiaramente le sue intenzioni, non ha bisogno di alcun commento e se non ho commesso errori dovrebbe anche compilare e funzionare :)

Certo, ci sono un paio di chiamate a funzioni, non e' efficiente come la prima versione, ma lascia che un profiler ci dica che e' questa funzione e' un punto critico dal punto di vista delle performance, e quando sappiamo che lo e', potremo sempre sostituire la versione piu' veloce, magari mantenendo la versione leggibile coperta da un #ifdef come documentazione.

Il mio consiglio e' il medesimo di Folwer e Beck (d'altronde mica me lo sono inventato io): quando senti il bisogno di commentare del codice perche' non e' chiaro, e' un segnale che il codice ti sta implorando per essere riscritto in maniera piu' chiara.

[DanieleC88]

Ho solo approfittato del tuo esempio interessante per introdurre il discorso sui commenti ;)
Era interessante? Davvero? :)
Mi sembrava solo un banalissimo esempio, ma, se lo dici tu, mi fido.
Il mio consiglio e' il medesimo di Folwer e Beck (d'altronde mica me lo sono inventato io): quando senti il bisogno di commentare del codice perche' non e' chiaro, e' un segnale che il codice ti sta implorando per essere riscritto in maniera piu' chiara.
Hai ragione. Io cerco di programmare, per quanto mi è possibile, in modo chiaro e ben commentato, ma d'ora in poi cercherò di rendere il codice autoesplicativo, senza il bisogno di commentare tanto.

[AnonimoVeneziano]

Personalmente ho sempre usato la sintassi : char *p

perchè sui libri dove ho imparato hanno sempre usato quella.

Probabilmente è vero che char* è migliore (il libro di Stroustrup che sto usando per il C++ dice così e anche per quanto riguarda dichiarazioni multiple di variabili sulla stessa linea come dice anche fek. Forse anche te fek ti sei riferito a quel libro riguardo questo suggerimento? ) , farò qualche prova

Ciao

[RaouL_BennetH]

Personalmente ho sempre usato la sintassi : char *p

perchè sui libri dove ho imparato hanno sempre usato quella.

Probabilmente è vero che char* è migliore (il libro di Stroustrup che sto usando per il C++ dice così e anche per quanto riguarda dichiarazioni multiple di variabili sulla stessa linea come dice anche fek. Forse anche te fek ti sei riferito a quel libro riguardo questo suggerimento? ) , farò qualche prova

Ciao

Stai leggendo C++ terza edizione?

L'ho comprato qualche giorno fa. :)

[^TiGeRShArK^]

in effetti è molto meglio scrivere codice "autocommentante" e levare i commenti....
io ho iniziato da stamattina :D
cmq è uscita una discussione molto interessante.
C'è qualke link dove ci sono altri esempi di come migliorare il codice o qualke libro???

[fek]

in effetti è molto meglio scrivere codice "autocommentante" e levare i commenti....
io ho iniziato da stamattina :D
cmq è uscita una discussione molto interessante.
C'è qualke link dove ci sono altri esempi di come migliorare il codice o qualke libro???


Libri? Quanti ne vuoi. Vai nel post in alto su questo forum e ne ho postati alcuni.
Code Complete 2 e Refactoring sono un must.

[71104]

vabbè, vorrei dire la mia e immagino che dopo tutto sto macello mi scannerete per ciò che dirò... :D
io uso qualcosa di simile alla notazione ungherese (non è una battuta per dire che la mia è una notazione arcana :D la notazione ungherese è proprio uno standard :read: )
più precisamente: io di solito l'asterisco lo metto davanti al nome della variabile, non dopo quello del tipo; inoltre quando devo dichiarare un lungo elenco di variabili tutte dello stesso tipo, le "raggruppo" in base alla loro funzionalità: variabili che servono a scopi simili le metto nello stesso elenco, variabili diverse invece le dichiaro separatamente :p
ad esempio, se devo dichiarare un array di int, una variabile che contenga il numero di elementi dell'array, e un contatore usato in for per ciclare sull'array, dichiaro il tutto in questa maniera:

int *pArr, nCount;
int i;

quanto vi siete inorriditi? :D

EDIT: non sono sicuro a dire il vero che le caratteristiche della notazione ungherese includano anche questo aspetto, so per certo che includono i prefissi delle variabili; a dire la verità infatti io mi sono semplicemente abituato allo stile Win32 degli esempi MSDN, e poi ho scoperto che la notazione di quegli esempi era quella ungherese... :rolleyes:

[71104]

ah, dimenticavo! che cos'è una idiosincrasia?!? :mbe:
(sono veramente riuscito a scriverlo?!?) :p

[71104]

bene: ho appena trovato un documento che descrive la notazione ungherese, e con la dichiarazione dei puntatori non c'entra un cà!!! :D
è semplicemente una notazione per i nomi dei tipi e delle variabili, nient'altro; corrisponde quasi completamente allo stile che uso io.

[VICIUS]

vabbè, vorrei dire la mia e immagino che dopo tutto sto macello mi scannerete per ciò che dirò... :D
io uso qualcosa di simile alla notazione ungherese (non è una battuta per dire che la mia è una notazione arcana :D la notazione ungherese è proprio uno standard :read: )
[...]
Personalmente trovo la notazione ungherese quanto di piu illeggibile esista sulla faccia della terra... m_lpstrzTunTanzUpzZap ... :rolleyes: mi chiedo come fanno i programmatori della ms a programmare con dei nomi cosi.

ciao ;)

[fek]

Personalmente trovo la notazione ungherese quanto di piu illeggibile esista sulla faccia della terra... m_lpstrzTunTanzUpzZap ... :rolleyes: mi chiedo come fanno i programmatori della ms a programmare con dei nomi cosi.

ciao ;)

Non programmano con la notazione ungherese infatti :)
E' un retaggio del C e dell'API Win32 che e' rimasta in C per compatibilita'.
Le nuove linee guida Microsoft vietano addirittura di usare la notazione ungherese.

[VICIUS]

Non programmano con la notazione ungherese infatti :)
E' un retaggio del C e dell'API Win32 che e' rimasta in C per compatibilita'.
Le nuove linee guida Microsoft vietano addirittura di usare la notazione ungherese.
Sono contento per loro. Costringerli a programmare in quel modo sarebbe stato un crimine. :asd:

ciao ;)

[fek]

int *pArr, nCount;
int i;

quanto vi siete inorriditi? :D


Abbastanza, io lo eviterei completamente :p

L'idea di raggruppare le variabili (o i membri di una classe) per gruppi funzionali e' ottima, studiamoci un po' su. Per un attimo pensiamo di programmare in C++ (o Java o C#) e non in C standard dove le variabili vanno dichiarate all'inizio. Correggetemi se sbaglio perche' saranno dieci anni che non scrivo una riga di C e non ricordo se e' solo il K&R a imporre la dichiarazione delle variabili temporanee all'inzio della funzione.

Io raggrupperei (e darei i nomi) cosi':


int* arrayOfIntegers;
int numberOfIntegers;

int i


Le prime due variabili fanno parte dello stesso gruppo funzionale e quindi sono dichiarate l'una dopo l'altra, metto un'interlinea e dichiaro l'ultima varaibile. Nota i nomi che ho dato, che secondo me sono piu' leggibili che usando la notazione ungherese. Qui c'e' un'interessante digressione da fare, secondo me. Che cosa rappresentano questi interi? Ad esempio possono rappresentare indici in un vettore, quindi al posto di chiamare le variabili con nomi "vicini al computer", le nomino con nomi "vicini al dominio del problema".

Proviamo cosi' e ci butto dentro anche del codice:


int* arrayOfIndices;
int numberOfIndices;

int i;

arrayOfIndices = (int *) malloc(sizeof(int) * SIZE_OF_ARRAY_OF_INDICES);
numberOfIndices = SIZE_OF_ARRAY_OF_INDICES;

for (i = 0; i < numberOfIndices; ++i)
{
arrayOfIndices[i] = i;
}



Nota come la variabile "i" e' dichiarata all'inizio ma usata dopo; senza entrare troppo nel merito della questione che Code Complete 2 spiega bene e definisce matematicamente, e' buona norma dichiarare le variabili vicino a dove sono usate, cosi':


int* arrayOfIndices;
int numberOfIndices;

// crea l'array di indici

arrayOfIndices = (int *) malloc(sizeof(int) * SIZE_OF_ARRAY_OF_INDICES);
numberOfIndices = SIZE_OF_ARRAY_OF_INDICES;

// inizializza l'array di indici
// Questo e' C++, non C
// Alcuni compilatori qui si comportano in maniera differente

for (int i = 0; i < numberOfIndices; ++i)
{
arrayOfIndices[i] = i;
}



Cosi' hai risolto il problema di dichiarare le variabili temporanee in gruppi funzionali ed hai un codice piu' leggibile. E scrivere codice piu' leggibile non e' fine a se' stesso, perche' questa versione ti sta suggerendo anche come migliorarla:



int* arrayOfIndices;
int numberOfIndices;

arrayOfIndices = CreateArrayOfIndices(&numberOfIndices);
IntializeArrayOfIndices(arrayOfIndices, numberOfIndices);


Ometto le due funzioni per non allungare troppo il post. Spero che tutto quello che ho scritto compili.

Ho detto che stiamo programmando in C++ ora, vero? A questo punto... :)


std::vector<int> arrayOfIndices;

for (int i = 0; i < SIZE_OF_ARRAY_OF_INDICES; ++i)
{
arrayOfIndices.push_back(i);
}


Volendo proprio fare i precisi si puo' scrivere il for con una semplice chiamata ad una funzione di STL. Chi se lo ricorda? Io a memoria non lo ricordo affatto.

[DanieleC88]

a dire la verità infatti io mi sono semplicemente abituato allo stile Win32 degli esempi MSDN
"Microsoft cripples your mind".
...o quello era il CoBOL? :p