[C] Dove mettete il * ?

[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-g...ml#declaration

[DanieleC88]

Che macello!
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]

Originariamente inviato da DanieleC88

Che macello!
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]

Originariamente inviato da fek

Adoro questa frase

Bella, piace anche a me.

[RaouL_BennetH]

Originariamente inviato da fek

"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]

Originariamente inviato da RaouL_BennetH

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]

Originariamente inviato da DanieleC88

#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]

Originariamente inviato da fek

E si puo' sempre migliorare.

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

Originariamente inviato da fek

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]

Originariamente inviato da DanieleC88

...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]

Originariamente inviato da fek

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.

Originariamente inviato da fek

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]

Originariamente inviato da 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

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
cmq è uscita una discussione molto interessante.
C'è qualke link dove ci sono altri esempi di come migliorare il codice o qualke libro???

[fek]

Originariamente inviato da ^TiGeRShArK^

in effetti è molto meglio scrivere codice "autocommentante" e levare i commenti....
io ho iniziato da stamattina
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ò...
io uso qualcosa di simile alla notazione ungherese (non è una battuta per dire che la mia è una notazione arcana la notazione ungherese è proprio uno standard )
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
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?

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...

[71104]

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

[71104]

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