Votre avis sur ce code

Version imprimable

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
char * now()
{
time_t curtime;
//struct tm * my_time;
 
        time(&curtime);
        int error=errno;
        if (!(errno)) return ctime(&curtime);
        else {fprintf(stderr,"now() : %s\n",strerror(error));exit(EXIT_FAILURE);}
 
}
 
char * day(char * d)
{
static  char dd[4];
        int error=errno;
 
 
        strncpy(dd,d,3);
        dd[3]='\0';
 
 
 
        if (!(errno)) return dd;
        else {fprintf(stderr,"day() : %s\n",strerror(error));exit(EXIT_FAILURE);}
 
}

Pour les fonctions ...

et pour le main()

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
int main () {
char c_date[30];
char c_day[4];
char n_day[3];
char c_month[4];
 
        while (TRUE)
        { 
 
        strcpy(c_date,now());
        strcpy(c_day,day(c_date));
       }
return 0;
 
}

Je pourrai me débrouiller avec des adresses de variables,
mais j'utilise le positionnement mémoire static .

Est-ce bien ?

8O

Voilà le type de code source que j'aime bien lire -- mais je ne donne que mon avis --
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 void* getElementEx(void *pTab,int posx,int posy,int posz,int nbcol,int nblig,int taille) { if(pTab==NULL) return 0; // perror devrait être modifié pour signaler le pointeur invalide if(nbcol<0) return 0; if(nblig<0) return 0; if(posz<0) posz=0; if(posy<0 || posy>nblig) return 0; // perror devrait être modifié pour signaler un effet de bord if(posx<0 || posx>nbcol) return 0; /*printf("Taille d'un void (%d), d'un void* (%d), d'un int (%d), d'un float (%d)...\n",sizeof(void),sizeof(void*),sizeof(int),sizeof(float)); printf("[DEMONSTRATION] pTab: %08x\n",pTab); printf("[DEMONSTRATION] pTab+1: %08x\n",pTab+(1*taille)); printf("[DEMONSTRATION] valeur trouvée à l'adresse de pTab: %4.2f\n",*((float*)pTab)); printf("[DEMONSTRATION] valeur trouvée à l'adresse de pTab+1: %4.2f\n",*((float*)pTab+1));*/ int offset=(posz*nbcol*nblig)+(posy*nbcol)+posx; return (void*)pTab+(offset*taille); }
Le nom des variables est censé être "parlant"... rien que le nom devrait indiquer à quoi cette variable est censée servir (ce qu'elle est censée contenir).
Je pourrais aller encore plus loin concernant la "nomenclature" (la façon de nommer les variables en fonction de leur type) ce qui permet de savoir rien qu'en lisant son nom de quel type elle est (l'incohérence se situe par rapport aux types définis par le programmeur).

Exemples:
Code:

1 2 3 4 préfixe str ou sz pour les chaînes de caractères préfixe i pour int préfixe ui pour unsigned int etc...

12/03/2021, 07h53
frederic13870

Oui, mais

J'ai entendu parlé de la syntaxe Camel.
C'est ce que tu as l'air d'utiliser.
Ce n'est pas un réflexe chez moi.

Quant au type des variables, je n'ai pas la même approche que toi.
Je préfère leur donner une signification plus proche de l'algorithme
car cela me facilite la relecture.

Bonne journée.
12/03/2021, 08h24
WhiteCrow

Citation:

Envoyé par frederic13870

[...]
Je pourrai me débrouiller avec des adresses de variables,
mais j'utilise le positionnement mémoire static .

Est-ce bien ?

8O

Bien ? Mal ? Ça va dépendre du contexte. Mais dans ton cas je dirais plutôt inutile.
Quand tu déclares une variable static dans le corps d'une fonction, tu crées une variable globale dont la durée de vie est celle du programme, mais dont la portée est locale à la fonction. Cela peut provoquer des races conditions/bugs dans le cas de programme multi threadé. D'ailleurs les fonctions de la libc qui utilisent des static de ce genre sont marquée MT unsafe, et possède des versions MT safe comme strtok/strtok_r.
Tu devrais, àmha, plutôt faire une fonction de ce que tu fais en ligne 12 du main …
12/03/2021, 13h30
frederic13870

Bon , d'accord

Tu me conseille de ne pas imbriquer les appels de fonctions ...

Pourquoi s.v.p ?
12/03/2021, 13h40
WhiteCrow

Ah non, je n'ai jamais dit qu'il ne fallait pas imbriquer les appels. Je dis, que pour ce que tu montres, autant faire une fonction de strcpy(c_day,day(c_date)); car cela te permettrait de ne pas utiliser de variable locale static.
12/03/2021, 14h12
Sve@r
Bonjour

On ne sort pas d'une fonction avec exit. C'est choisir une solution de facilité parce qu'on ne veut pas s'embêter à gérer un souci. Mais si les programmeurs de la fonction time() avaient fait comme toi, tu ne saurais pas qu'il y a erreur. Donc soit tu ne gères pas, soit tu gères mais alors tu gères complètement. Pas ce truc douteux entre la chèvre et le chou. C'est pire de mal faire que de ne rien faire.
Une fonction ne peut pas faire son job? Ok. Alors elle retourne une valeur spéciale à l'appelant qui peut alors gérer le cas et s'il ne peut pas, lui-aussi retourne une valeur spéciale à son propre appelant et ainsi de suite jusqu'au main() qui, seul, a le droit de quitter.

Je ne comprends pas trop le but de la fonction day. Il existe une structure "struct tm" qui contient tous les détails d'une date, y compris le jour de la semaine (champ tm_wday). Pas besoin de ce tripatouillage de string qui s'appuie sur la langue utilisée pour fonctionner. En plus comme l'a dit WhiteCrow, le static détruit l'indépendance de la fonction (tu ne peux pas l'appeler plus d'une fois à la fois). Ok tu t'en sors car tu prends soin de vite récupérer son contenu avant un autre appel mais ça reste une fonction unsafe. Une bonne fonction recevrait la chaine originelle et l'espace où stocker la copie et n'aurait pas besoin de static. Elle pourrait même pousser le luxe jusqu'à recevoir aussi la taille de la zone réceptrice pour être sûre de ne pas dépasser et... ben oui, cette fonction existe déjà => strncpy(). Donc un simple strncpy() au lieu de faire strcpy(..., strncpy()) (ben oui, tu appelles day qui ne fait en réalité rien d'autre qu'un strncpy).

On ne détecte pas une erreur système en regardant errno. errno est une variable globale qui ne sert pas à indiquer s'il y a erreur mais une fois que l'erreur est détectée, à indiquer la cause de l'erreur et ce n'est pas la même chose. Et en plus elle peut être modifiée par n'importe quel appel système (elle peut donc être modifié ailleurs alors que de ton côté ça se passe bien). Tu veux tester time() pas de souci mais alors tu testes réellement time(), pas son ricochet. Et bon c'est bien de récupérer errno dans error au cas où mais alors il ne faut plus utiliser ensuite errno (le "if()" de la ligne suivante). Hé oui, faut être cohérent avec soi-même. Soit tu as peur de perdre errno qui serait modifié éventuellement entre temps et donc une fois récupéré tu l'oublies définitivement, soit tu n'as pas peur de l'utiliser et dans ce cas, le copier dans error ne sert à rien. Accessoirement aller jusqu'à tester strncpy() c'est peut-être pousser le bouchon un peu loin. Le trop est l'ennemi du bien. D'autant plus que strncpy() ne peut pas échouer et donc errno ne sera pas affecté par cette fonction. Et bon le if (!(errno)) montre que tu n'as peut-être pas bien saisi le but des parenthèses qui est de regrouper des opérations, pas des valeurs (une valeur un truc atomique donc insécable). Ce regroupement permet de prioriser une opération habituellement non prioritaire (ex (2+3)*4 qui sera différent de 2+3*4). Donc les parenthèses impliquent
1. au-moins un opérateur dans l'expression entre parenthèses
2. cette expression suivie ou précédée elle-aussi d'un opérateur
3. l'opérateur dans les parenthèses est de priorité moins élevée que l'opérateur qui va la traiter (inutile par exemple d'écrire 2+(3*4) là où 2+3*4 donne le même résultat)
Alors autant la 3° règle n'est pas gravée dans le marbre. En effet, face à l'arithmétique "traditionnelle" qui possède 3 niveaux de priorités failes à maîtriser (+-, */, puissances), le C en possède 15 qui vont tantôt de gauche à droite, tantôt de droite à gauche et même celui qui les connait tous par coeur aura quand-même du mal à lire une expression un peu complexe (ex pt->i++ * 2 > 5 & 0x0f) sans parenthèses placées à certains moments clefs de l'expression, autant les deux premières sont incontournables ce qui n'est pas le cas dans ton if (!(errno)) qui pourra s'écrire plus simplement if (!errno) ou, mieux, if (errno == 0) (parfois écrire explicite ne fait pas de mal question lisibilité).

Et sinon tu te trompes, la syntaxe mentionnée par hurukan (rajouter un "i" pour "int" etc) ce n'est pas la syntaxe camel mais la notation hongroise et plus précisément la branche "Systems", notation que je n'aime pas vraiment non plus. La notation camel c'est mettre des majuscules pour symboliser l'espace permettant de commencer un mot => ex int dureeDeVie indiquant que cette variable exprimera une durée de vie. Celle là je l'aime bien.
12/03/2021, 14h36
frederic13870

Citation:

Envoyé par WhiteCrow

D'accord. C'est plus clair

Citation:

Envoyé par Sve@r

Ok, Mais c'est beaucoup plus lourd.
La durée de develop s'allonge aussi.

Citation:

Envoyé par frederic13870

La durée de develop s'allonge aussi.

Tu parles de la gestion d'erreur ? Ben oui, faire les choses bien prend plus de temps que bosser à la "va-vite", ce n'est pas nouveau ; et ce n'est même pas inhérent à l'informatique. Et alors?

C'est vrai que remplacer...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 char* now() { time_t curtime; time(&curtime); int error=errno; if (!(errno)) return ctime(&curtime); else { fprintf(stderr,"now() : %s\n",strerror(error)); exit(EXIT_FAILURE); } } int main () { char c_date[30]; char c_day[4]; char n_day[3]; char c_month[4]; while (TRUE) { strcpy(c_date,now()); strcpy(c_day,day(c_date)); } return 0; }
... par ...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 char* now() { time_t curtime; if (time(&curtime) < 0) return NULL; return ctime(&curtime); } int main () { char c_date[30]; char c_day[4]; char n_day[3]; char c_month[4]; c_day[3]='\0'; while (TRUE) { char *pt; if ((pt=now()) == NULL { int error=errno; fprintf(stderr, "now() : %s\n", strerror(error)); return EXIT_FAILURE; } strcpy(c_date, pt); strcnpy(c_day, pt, 3); } return 0; }
... est en effet un petit peu plus long mais est-ce vraiment trop long? Ca te permet de mieux affiner aussi la gestion d'erreurs. Aujourd'hui on quitte sur souci, et on quitte dans le main ce qui est ok, mais demain on pourra se contenter d'abandonner l'itération en cours et taper un continue pour passer à la suivante (ok peut-être rajouter un compteur d'échecs pour éviter la boucle infinie).
Et puis sinon, comme je l'ai dit, tu peux gérer les erreurs ou ne pas les gérer. Donc cela s'applique aussi à l'appelant qui n'est pas obligé lui de gérer le retour NULL ou pas. Mais au-moins ta fonction à toi est propre.

13/03/2021, 08h06
Christophe

Citation:

La durée de develop s'allonge aussi.

oui mais réduit le temps de débogage. et déboguer c'est toujours plus long que développer.