Bonjour,

Suite à diverses discussions que j'ai eu sur différents forums à propos du coté 'rigide' de cette école en matière de règles de codage, je me propose d'apporter mes remarques sur ces règles.

Le texte :

http://www.epitech.net/intra/docs/norme.html

Sauf exception, je ne commente pas les points sur lesquels je suis d'accord.

Citation : La nomination des objets

seuls les nom de macros sont en majuscules, tout les autres (variables, fonctions, types, fichiers, rep...) sont en minuscules.

- on dit nommage ou dénomination
- "les noms"

Erreur classique.

La vraie règle d'usage concerne les identificateurs définissant des expressions constantes ou des chaines de caractères, comme certaines macros (mais pas les function-like macros) et les enums.

Citation : Présentation globale

int		get_type(char type_char)
{
  t_types	*types;

  
  types = types_tab;
  while (types->type_val)
  {
    if (types->type_val == type_char)
      return (types->type_val);
    types++;
  }
  return (FALSE);
}

Plusieurs choses me choquent dans cet exemple de présentation.

1 - l'usage du caractère TAB dans le source, qui a pour effet de créer des espaces surréalistes...

2 - 2 lignes vides alors qu'une suffit.

3 - pas de {} avec la structure de code if, ce qui ralentit la mise au point et l'évolution du code.

4 - parenthèses inutiles avec return.

Sur le plan C pur, il y aurait à redire, mais je suppose que ce n'était pas le but de cet exemple.

Si on s'en tient à la présentation, mon indenteur propose :

int get_type (char type_char)
{
   t_types *types;

   types = types_tab;
   while (types->type_val)
   {
      if (types->type_val == type_char)
         return (types->type_val);
      types++;
   }
   return (FALSE);
}

Que je complète comme ceci :

int get_type (char type_char)
{
   t_types *types = types_tab;

   while (types->type_val)
   {
      if (types->type_val == type_char)
      {
         return types->type_val;
      }
      types++;
   }
   return FALSE;
}

EDIT : suppression des () du 1er return.

Citation : Présentation globale

On passe toujours a la ligne après '{', '}' ou une structure de contrôle. On indente une première fois pour les accolades, puis une seconde pour leur contenu.

Pas d'accord pour la 2 ème fois. Ça surcharge le codage inutilement et ça créée un excès d'indentation qui nuit à la lisibilité.

Citation : Présentation globale

On alignera les noms des variables sur le nom de la fonction qui les contient et uniquement celle ci.

Bah, non. On suit l'indentation par défaut, c'est beaucoup plus clair (et automatisé)... De plus, on peut définir des variables au début de n'importe quel bloc, à moins que ça aussi, ça ne soit interdit !

Citation : Présentation locale

Pas d'espace entre le nom d'une fonction et la '(', par contre toujours un espace entre un mot clé C (avec argument) et la '('

OK dans le principe, malheureusement, les indenteurs que je connais ne font pas la différence, et il est impensable que je repasse derrière pour corriger à la main... Pas que ça à faire...

Citation : suite

Ceci concerne while, etc... et aussi return, mais pas sizeof qui est une expression renvoyant une valeur.

return ? Pouquoi ? Il faut des parenthèses à return ?

quand à sizeof, la syntaxe est

sizeof variable 
sizeof (type)

donc, ça dépend des cas. Certains auteurs prétendent que les parenthèses autour du type sont assimilables à un 'cast' et qu'elles appartiendraient donc au type (et non à sizeof).

Citation : suite

On remarquera que return est une structure de contrôle du C, et exit une fonction, donc attention aux espaces devant la parenthèse.

Au lieu de perdre son temps à compter les espaces, ne pas mettre de parenthèses à return...

Curieux sens de la productivité pour une école privée...

Citation : suite

Lorsque return prend un argument, ce dernier doit être entre parenthèses:

La cerise sur le gâteau...

Citation : Présentation locale

Le symbole de pointeur (*) porte toujours sur la variable (ou fonction), et jamais sur le type:

char	*cp;	/* Correct */
char*	cp;	/* Incorrect */

On atteint les sommets de l'absurdité... Il vaudrait mieux imposer un préfixe p aux identificateurs de pointeurs. Ce serait beaucoup plus utile...

Citation : Présentation locale

On alignera les déclarations avec des tab

Pas contre en théorie, mais en pratique, le comportement d'un TAB n'est pas portable, alors pas de TAB chez moi. Donc, pas d'alignement des identificateurs...

Citation : Présentation locale

Lorsqu'on déclare une variable on ne peut affecter en même temps une valeur excepte lorsqu'on utilise une variable static.

Très grosse ânerie. Il est des cas où la non initialisation est utile et d'autres où c'est l'initialisation qui est utile.

Il est absurde de faire une fixation sur la déclaration des données qui ne sont qu'un détail d'implémentation du langage C. Dans bien des langages, le type est donné automatiquement lors de la première affectation de la variable (la seule qui compte réellement).

x := 12 // INTEGER
y := 12. // REAL
z := 'A' // CHARACTER
t := "hello" // STRING

Citation : Présentation locale

Les #if et #ifdef indentent d'un caractère les directives cpp qui suivent. Les #else et #endif marquent les conditions dont ils sont issus.

Pas contre en théorie, sauf qu'un jour, dans un gros projet industriel, j'ai passé 2 jours à comprendre qu'une obscure moulinette intermédiaire (en gros, elle se servait des directives de préprocesseur d'un code écrit en C pour générer un code source en assembleur qui utilisait les mêmes constantes...) ne supportait pas cette syntaxe... Depuis, j'évite les exotismes, même standards...

Citation : Interdits

Vous n'avez pas droit aux mots switch et for.

OK, on peut s'en passer, mais encore une fois, c'est contre-productif.

De plus un switch-case bien écrit (constantes dans l'ordre avec une relation simple entre elles) est souvent très bien optimisé par le compilateur...

Citation : Interdits

Les macros multilignes

On pourrait être plus souple (disons 3/4 lignes max)...

Citation : Headers

Si le fichier est foo.h, la macro témoin est FOO_H_

OK dans le principe, mais plusieurs remarques :
- Le _ final est inutilement laid. FOO_H est OK et plus lisible.
- Je conseille d'écrire H_FOO. Ca évite les noms interdits comme ERREUR_H (E suivit d'une majuscule est réservé à l'implémentation).
- Il a été oublié un point essentiel, c'est qu'une garde doit être unique (un cas de doublon est catastrophique). Personnellement, j'ajoute les initiales de l'auteur et une datation sous la forme YYYYMMDDHHMMSS

Citation : Headers

# foo.c inclue toujours foo.h.
# Les headers ne doivent pas faire d'include eux-mêmes. A l'extrême limite on pourra inclure des headers non systèmes, mais jamais d'inclusion de headers systèmes.

OK pour le 1er point. Par contre le 2ème est absurde... Il est en effet utile qu'un header soit 'autonome' et qu'il puisse compiler même si il est inclus en 1er dans un code source (foo.c, par exemple, comme, je le recommande).

Si un prototype de fonction utilise un paramètre ou un retour de type size_t, div_t (c'est pas interdit au moins ?) ou FILE *, il faut bien que respectivement <stddef.h>, <stdlib.h> et <stdio.h> soient inclus dans le header, sinon, il y a erreur. C'est la même démarche que pour les types utilisateur pour lesquelles cette action semble tolérée en se bouchant le nez...

Il n'y a vraiment pas de quoi, et ce principe est largement utilisé avec succès dans l'industrie. Il s'appuie d'ailleurs sur les protections contres les inclusions multiples dans la même unité de compilation dont l'usage est universellement recommandé (y compris par ce document).

Je ne suis pas trop d'accord avec certaines des recommandations qui suivent, mais comme elles ne sont pas obligatoire, je n'insitste pas.

Je ne commente pas les Makefile.

Conclusion

C'est bien de donner des règles, mais il ne faut pas oublier celles qui rendent le code meilleur et pas se contenter de contraintes arbitraires.

http://mapage.noos.fr/emdel/codage.htm

Hahaha!!! J'adore, je fais tourné le poste a épitech! Promis (a)
J'ai juste une réponse: la moulinette à toujours raison!

Citation : Mafyou

J'ai juste une réponse: la moulinette à toujours raison!

Est-ce que l'indenteur automatique est fourni ? Des règles rigides appliquées à la main sont contre-productives...

oui!
Pour indenté, on se fit uniquement aux tab de emacs (sous FreeBSD) avec sont "alt+i"

Bonjour,

Je m'en vais de mon petit avis personnel :

La norme est faite pour inciter les étudiants à avoir un code homogène, et facilement compréhensible par les autres étudiants. (pour l'entre-aide par exemple, ou les corrections)
Certaines contraintes sont également présentes afin d'éviter des monstruosités couramment constatées. (même si elles peuvent sembler stupide à première vue)
Bien sûr, cela empêche parfois de faire des choses qui ont du sens, et qui seraient justifiés. Dommages collatéraux

D'autre part, j'ajouterai que dans les faits, seuls les étudiants de première et de deuxième années sont soumis à cette contrainte.
Par la suite, le non respect de la norme n'est pas vraiment pénalisé, mais les étudiants continues de se conformer aux points essentiels de cette dernière (pour une raison de clarté :)).

Citation : -ed-

Citation : La nomination des objets

seuls les nom de macros sont en majuscules, tout les autres (variables, fonctions, types, fichiers, rep...) sont en minuscules.

La vraie règle d'usage concerne les identificateurs définissant des expressions constantes ou des chaines de caractères, comme certaines macros (mais pas les function-like macro) et les enums.

Les "function-like" sont déconseillé, pour éviter certains contournement de norme, poussant à faire un code affreux

Citation : -ed-

Citation : Présentation globale

int		get_type(char type_char)
{
  t_types	*types;

  
  types = types_tab;
  while (types->type_val)
  {
    if (types->type_val == type_char)
      return (types->type_val);
    types++;
  }
  return (FALSE);
}

Plusieurs choses me choquent dans cet exemple de présentation.

2 - 2 lignes vides alors qu'une suffit.

C'est une erreur. Il ne doit y avoir qu'une seule ligne enfait.

Citation : -ed-

4 - parenthèses inutiles avec return.

Ça permet d'"englober" ce qui est retourné, uniquement dans un but de compréhension/relecture.

Citation : -ed-

Citation : Présentation globale

On passe toujours a la ligne après '{', '}' ou une structure de contrôle. On indente une première fois pour les accolades, puis une seconde pour leur contenu.

Pas d'accord pour la 2 ème fois. Ça surcharge le codage inutilement et ça créée un excès d'indentation qui nuit à la lisibilité.

L'indentation des accolades est facultative.
Il me semble parcontre que c'est l'indentation par défaut d'emacs, donc au final, cette règle est souvent appliquée.

Citation : -ed-

Citation : Présentation globale

On alignera les noms des variables sur le nom de la fonction qui les contient et uniquement celle ci.

Bah, non. On suit l'indentation par défaut, c'est beaucoup plus clair (et automatisé)... De plus, on peut définir des variables au début de n'importe quel bloc, à moins que ça aussi, ça ne soit interdit !

C'est pratique d'avoir tout aligné au même endroit, ça évite d'avoir à se balader.
Et pour les variables, elles ne doivent être déclarées qu'en début de fonction (ou avant, pour les globales/...)

Citation : -ed-

Citation : Présentation locale

Pas d'espace entre le nom d'une fonction et la '(', par contre toujours un espace entre un mot clé C (avec argument) et la '('

OK dans le principe, malheureusement, les indenteurs que je connais ne font pas la différence, et il est impensable que je repasse derrière pour corriger à la main...

Les bons éditeurs, ça doit pouvoir se configurer...
Encore une fois, la plupart du dev des deux premières années se fait sous emacs (ou vi), donc c'est fait à la main

Citation : -ed-

Citation : suite

Ceci concerne while, etc... et aussi return, mais pas sizeof qui est une expression renvoyant une valeur.

return ? Pouquoi ? Il faut des parenthèses à return ?

Comme tu l'as fait remarquer plus haut, oui.

Citation : -ed-

quand à sizeof, la syntaxe est

sizeof variable 
sizeof (type)

? Là je ne vois pas bien.

Il me semble bien que :

sizeof(int);

et

int i;
sizeof(i);

sont semblable.

Citation : -ed-

Au lieu de perdre son temps à compter les espaces, ne pas mettre de parenthèses à return...

Curieux sens de la productivité pour une école privée...

C'est une école, les étudiants sont là pour apprendre, ils ont le temps (jusqu'au rendu du projet).
Le but n'est donc pas de réaliser un projet le plus rapidement possible.
Et de toute façon, après quelques mois (au maximum), la "mise à la norme" est instantanée, sans même avoir besoin d'y réfléchir.

Citation : -ed-

Citation : Présentation locale

On alignera les déclarations avec des tab

Pas contre en théorie, mais en pratique, le comportement d'un TAB n'est pas portable, alors pas de TAB chez moi. Donc, pas d'alignement des identificateurs...

De nombreux éditeurs admettent qu'une tab fait 8 espaces, les autres sont configurables
Mais je suis d'accord que ce n'est pas portable. D'où l'intérêt des éditeurs qui permettent de configurer le nombre d'espaces que prend une tabulation, et ensuite de toujours travailler avec des espaces.

Citation : -ed-

Citation : Présentation locale

Lorsqu'on déclare une variable on ne peut affecter en même temps une valeur excepte lorsqu'on utilise une variable static.

Très grosse ânerie. Il est des cas où la non initialisation est utile et d'autres où c'est l'initialisation qui est utile.

Il est absurde de faire une fixation sur la déclaration des données qui ne sont qu'un détail d'implémentation du langage C. Dans bien des langages, le type est donné automatiquement lors de la première affectation de la variable (la seule qui compte réellement).

Euh... la norme n'explique pas comment fonctionne le C, c'est principalement esthétique.
Puis d'ailleurs, c'est une norme pour le langage C, donc les types sont explicites.

Citation : -ed-

Citation : Présentation locale

Les #if et #ifdef indentent d'un caractère les directives cpp qui suivent. Les #else et #endif marquent les conditions dont ils sont issus.

Pas contre en théorie, sauf qu'un jour, dans un gros projet industriel, j'ai passé 2 jours à comprendre qu'une obscure moulinette intermédiaire (en gros, elle se servait des directives de préprocesseur d'un code écrit en C pour générer un code source en assembleur qui utilisait les mêmes constantes...) ne supportait pas cette syntaxe... Depuis, j'évite les exotismes, même standards...

Oui enfin, si on devait se conformer à tous les outils mal codés, nous ne ferions plus grand chose.

Citation : -ed-

Citation : Interdits

Vous n'avez pas droit aux mots switch et for.

OK, on peut s'en passer, mais encore une fois, c'est contre-productif.

De plus un switch-case bien écrit (constantes dans l'ordre avec une relation simple entre elles) est souvent très bien optimisé par le compilateur...

C'est dommage, mais cette règle est là pour éviter certaines dérives encore une fois.
Et concernant le for, il me semble qu'il est admis à partir de la deuxième année.

Et pour le compilateur (gcc), il me semble (pas certain) qu'il optimise d'une façon semblable une suite de if/else if utilisé comme un switch.

Citation : -ed-

Citation : Interdits

Les macros multilignes

On pourrait être plus souple (disons 3/4 lignes max)...

C'est nouveau ça... encore une fois, les dérives...
Mais c'est vrai que c'est parfois bien pratique.

Citation : -ed-

Citation : Headers

Si le fichier est foo.h, la macro témoin est FOO_H_

- Il a été oublié un point essentiel, c'est qu'une garde doit être unique (un cas de doublon est catastrophique). Personnellement, j'ajoute les initiales de l'auteur et une datation sous la forme YYYYMMDDHHMMSS

C'est rare d'avoir plusieurs .h nommés de la même façon, surtout sur de "petits" projets.

Citation : -ed-

Si un prototype de fonction utilise un paramètre ou un retour de type size_t, div_t (c'est pas interdit au moins ?) ou FILE *, il faut bien que respectivement <stddef.h>, <stdlib.h> et <stdio.h> soient inclus dans le header, sinon, il y a erreur.

Entièrement d'accord là dessus.
Encore une fois, en pratique, c'est "toléré" quand il y a une réelle justification.

Voilà, je répète que ces commentaires n'engage que moi

Bonne journée.

Citation : Mafyou

oui!
Pour indenté, on se fit uniquement aux tab de emacs (sous FreeBSD) avec sont "alt+i"

Je ne crois pas que c'est ce que -ed- entendait par indenteur automatique. Est-ce qu'on vous fournit à EPITECH une ligne d'options pour GNU Indent ou astyle, histoire d'automatiser un minimum la mise en forme du code ?

Thierry

Non non, tout à la main.
Le but est que les étudiants apprennent à coder "proprement", donc ce serait bête de fournir une automatisation.

Citation : Kun

Non non, tout à la main.
Le but est que les étudiants apprennent à coder "proprement", donc ce serait bête de fournir une automatisation.

Lorsque je lis le document donné en lien par -ed-, je me pose des questions sur le "proprement".

Thierry

Le document que montre -ed- n'est pas vraiment une reference pour le norme EPITECH. Il manque beaucoup de choses, et au contraire, certaines sont exagerees, comme l'interdiction d'inclure des headers system dans nos propores headers par exemples, et ne sont pas forcement appliquees.

Le but de la norme est au final d'avoir un style de codage assez uniforme pour que tout le monde puisse comprendre très rapidement le code de quelqu'un d'autre, et ainsi l'aider. En tant qu'ancien assistant des première année, je peux dire que c'est tres efficace.

Enfin un autre but est d'apprendre la rigueur, puisque le non respect de la norme n'est pas du tout pardonne, mais c'est une autre histoire.

Citation

Lorsque je lis le document donné en lien par -ed-, je me pose des questions sur le "proprement".

Encore une fois, ce document n'a pas pour but de montrer du code, juste du style de codage. Je peux t'assurer qu'un projet conçue des le départ dans le respect de cette norme, aura un code souvent très propre (ou clair au moins).

Bonjour, je ne poste pas souvent mais je ne résiste pas aujourd'hui à l'envie de poster ici-même.
Notez qu'en ce qui concerne le reste du sujet, je ne me prononce pas.

Citation : Kun

Citation : -ed-

Citation : Headers

Si le fichier est foo.h, la macro témoin est FOO_H_

- Il a été oublié un point essentiel, c'est qu'une garde doit être unique (un cas de doublon est catastrophique). Personnellement, j'ajoute les initiales de l'auteur et une datation sous la forme YYYYMMDDHHMMSS

C'est rare d'avoir plusieurs .h nommés de la même façon, surtout sur de "petits" projets.

Mais il n'est pas rare d'avoir des fichiers qui commencent pas un 'e'. D'où l'importance de citer toutes les remarques de -ed-.

Citation : -ed-

Citation : Headers

Si le fichier est foo.h, la macro témoin est FOO_H_

OK dans le principe, mais plusieurs remarques :
- Le _ final est inutilement laid. FOO_H est OK et plus lisible.
- Je conseille d'écrire H_FOO. Ca évite les noms interdits comme ERREUR_H (E suivit d'une majuscule est réservé à l'implémentation).
- Il a été oublié un point essentiel, c'est qu'une garde doit être unique (un cas de doublon est catastrophique). Personnellement, j'ajoute les initiales de l'auteur et une datation sous la forme YYYYMMDDHHMMSS

Cette convention me semble donc sur ce point particulièrement casse-gueule. Je trouve même que c'est une erreur grossière de la part d'une école, sensée apprendre à éviter ce genre de pièges.

Salut,
Tu comptes recense tous les epitechiens présent sur le SDZ avec les réponses de ce poste?
On sait que tu ne supportes pas les unif ou haute école tu l'a assez dit par toi même.

La norme bien qu'on ne soit pas toujours d'accord avec elle, permet au etudiant de se relire entre eux sans avoir a attraper la migraine.
Le document que tu montre n'est pas vraiment a jour.
Pour ce qui est des headers c'est n'importe quoi car la moulinette ne corrige que les fichier .c

L'envie de faire un ticket au bocal avec l'url me tente bien, je sais ce que je ferais au prochain PC non logue en absence de son propriétaire ...

Citation : bleus_d

Tu comptes recense tous les epitechiens présent sur le SDZ avec les réponses de ce poste?

Euh, non. Pourquoi ferais-je ça ?

Citation : Pas de titre

On sait que tu ne supportes pas les unif ou haute école tu l'a assez dit par toi même.

J'essaye de rester objectif. Il y a des choses qui me choquent, et j'ouvre une discussion dessus. C'est grave ?

Citation : Pas de titre

Le document que tu montre n'est pas vraiment a jour.

Je veux bien celui qui est à jour.

Ca, c'est OK ?

http://www.shtark.fr/etudes/norme-epitech/

Ce qui est dit a l'air juste, sauf l'interdiction des break/continue qui est tolérée quand elle est bien justifiee.

Et l'histoire des parantheses n'est pas tres clair je trouve. En gros

int    test(int nb, char *str)
{
  while (((nb + 1) < 10) && str[nb])
    {
      test2(nb, str);
      ...
    }
  ...
  return (nb);
}

sont des parantheses a la norme.

La syntaxe MY_H_ de `#ifndef MY_H_' n'est pas obligatoire non plus.

Je pense pas qu'il y ait de document a jour decrivant exhaustivement la norme a Epitech. Ca se transmet de teks en teks !

Il manque des choses importantes comme par exemple l'interdiction de mettre plus de 4 paramètres à une fonction.

Pour ce qui est de l'utilisation des switch, for, c'est interdit. (en C et en 1ère année du moins).

Sinon je ne vois pas trop l'intérêt de poster ces règles sur un forum, la norme Epitech est assez contraignante surtout au début mais elle est là pour de bonnes raisons et heureusement qu'elle existe et qu'elle est aussi sévère.

Il n'y a qu'a voir les codes que certains sortent alors qu'il y a ces règles, si elles existaient pas je n'ose pas imaginer la difficulté pour les Astek de passer derrière certains codes.

Sinon hormis pendant les colles les correcteurs sont "relativement" souples il faut le dire.

Salut,

Citation : as32

Je pense pas qu'il y ait de document a jour decrivant exhaustivement la norme a Epitech. Ca se transmet de teks en teks !

Pour le jazz manouche, je peux comprendre le pourquoi du comment de la tradition orale, mais pour des règles de codage... J'ai quand même un peu de mal.

A+

Pfeuh

Citation : -ed-

Citation : bleus_d

Tu comptes recense tous les epitechiens présent sur le SDZ avec les réponses de ce poste?

Euh, non. Pourquoi ferais-je ça ?

Je ne sais pas mais je ne vois pas l'utilite de ce poste sur un forum C d'un site d'entraide.
Tu incrimines une norme la ou il n'y aura pas de gens pour la défendre si ce n'est les étudiants qui la suivent. (malgré eux).

Citation : -ed-

Citation : Pas de titre

On sait que tu ne supportes pas les unif ou haute école tu l'a assez dit par toi même.

J'essaye de rester objectif. Il y a des choses qui me choquent, et j'ouvre une discussion dessus. C'est grave ?

Oui car de loin tu manipules les gens que ce soit ton but ou non.
Ton expériences et ta notoriété font que d'autre membres lisant ce poste sans avoir forcement toutes les compétences pour le comprendre ce range de ton cote et perdre leur libre arbitre.

Citation : -ed-

Citation : Pas de titre

Le document que tu montre n'est pas vraiment a jour.

Je veux bien celui qui est à jour.

Ca, c'est OK ?

http://www.shtark.fr/etudes/norme-epitech/

Non, le seul moyen d'être a jour est d'avoir la moulinette de paris ...
La norme est une transmission d'astek et aer au tek1 puis fonction de ce que la moulinette nous dis dans les emails suivant les rendu.

PS: qui veut un norme.sh? (ok je suis déjà loin dehors )

Citation : pfeuh

Citation : as32

Je pense pas qu'il y ait de document a jour decrivant exhaustivement la norme a Epitech. Ca se transmet de teks en teks !

Pour le jazz manouche, je peux comprendre le pourquoi du comment de la tradition orale, mais pour des règles de codage... J'ai quand même un peu de mal.

+1 !

On est bien d'accord on a pas dis qu'on appréciait la norme des -8 pour norme et passe de 19 a 11 et du coup rater sa piscine c'est chiant.
On sait tous que la norme est foireuse sur bien des points mais je reste persuader que tous coder celons les même règles (bonne ou non) fait gagner un temps fou.

Citation : bleus_d

On est bien d'accord on a pas dis qu'on appréciait la norme des -8 pour norme et passe de 19 a 11 et du coup rater sa piscine c'est chiant.
On sait tous que la norme est foireuse sur bien des points mais je reste persuader que tous coder celons les même règles (bonne ou non) fait gagner un temps fou.

On est d'accord. Je voulais juste souligner les points douteux, afin que les utilisateurs puissent prendre du recul. C'est tout. Mon but est d'aider les gens à écrire du code correct, c'est tout.

Citation : Pas de titre

je ne vois pas l'utilite de ce poste sur un forum C d'un site d'entraide.

Site d'entraide ? Tu parles de quoi ? On est sur le forum C du Site du Zéro dont le but est "de tout apprendre à partir de "zéro". C'est donc essentiellement un site de formation. Discuter des normes de codages du langage C (qui plus est fournis par une école, donc qui fait aussi de la formation) me parait tout à fait approprié. Mettre le doigt sur les points améliorables aussi. Il est même plutôt curieux que tu n'en vois pas l'utilité...

Citation : Pas de titre

Tu incrimines une norme

Je n'incrimine pas. Il faut rester calme. Je fais des remarques, c'est tout. Tu penses que rien n'est améliorable, que le monde est figé définitivement ?

Citation : Pas de titre

la ou il n'y aura pas de gens pour la défendre

J'ai eu des justifications, dont certaines que je n'ai pas contesté. Je trouve que le débat est plutôt bien engagé. Au lieu de me faire des procès d'intentions, tu ferais mieux de débattre sur le fond...

Citation : Pas de titre

Oui car de loin tu manipules les gens que ce soit ton but ou non.
Ton expériences et ta notoriété font que d'autre membres lisant ce poste sans avoir forcement toutes les compétences pour le comprendre ce range de ton cote et perdre leur libre arbitre.

Ce sont donc bien les disciples qui créent les gourous, c'est bien ce qui me semblait...

Si mon expérience (réelle) et ma notoriété (supposée) peuvent faire avancer les choses dans le domaine du codage, je n'aurais pas été complètement inutile sur cette terre. Oui.

Je tiens à réagir à propos de cette norme de codage, qui m'a choquée également, surtout pour une école. J'ai eu grosso modo les mêmes appréciations que celles de -ed-.

Citation : -ed-

Que je complète comme ceci :

int get_type (char type_char)
{
   t_types *types = types_tab;

   while (types->type_val)
   {
      if (types->type_val == type_char)
      {
         return (types->type_val);
      }
      types++;
   }
   return FALSE;
}

Je dirais que tu as oublié d'enlever les parenthèses au premier return -ed- ?

Citation : Kun

Et pour les variables, elles ne doivent être déclarées qu'en début de fonction

Non, au début de n'importe quel bloc d'accolades :

void foo (void)
{
  int bar;
  {
    int foobar;
  }
  /* 'foobar' non declaree ici */
}

Citation : Kun

C'est une école, les étudiants sont là pour apprendre, ils ont le temps (jusqu'au rendu du projet).

Ce n'est pas parce qu'on a le temps qu'on peut le perdre.

Citation : Kun

De nombreux éditeurs admettent qu'une tab fait 8 espaces, les autres sont configurables

On ne va pas commencer à configurer son éditeur pour chaque code source d'une provenance différente ? Et que fait-on si on veut lire à la fois un code source en mode mélangé de Emacs et un code qui indente à coups de tabulations ? Je soutiens l'indentation via espaces.

Citation : Kun

Et concernant le for, il me semble qu'il est admis à partir de la deuxième année.

Pourquoi ? Un motif particulier ? for est trop complexe pour les novices ? Si on veut parcourir un tableau en première année, j'en déduis que l'on doit utiliser une boucle while, moins lisible à cet effet ? Quel intérêt de se passer de la puissance d'un langage ?

Citation : Yno

Je tiens à réagir à propos de cette norme de codage, qui m'a choquée également, surtout pour une école. J'ai eu grosso modo les mêmes appréciations que celles de -ed-.

Citation : -ed-

Que je complète comme ceci :
<...>

Je dirais que tu as oublié d'enlever les parenthèses au premier return -ed- ?

Ah, il y avait un deuxième return ? Alors ça c'est contre mes règles de codages qui sont basées sur les principes de la programmation structurée... autre débat...

OK pour supprimer ces parenthèses aussi, évidemment. Correction faite.

"nomination" : les variables ne postulent pas aux Oscars.

"Les objets (variables, fonctions, macros, types, fichiers ou répertoires)" : une fonction, une macro, un type n'est pas un objet aux sens du C.

"Tous les identifiants (fonctions, macros, types, variables etc.) " confusion "identifiant" et "identificateur"

"seuls les nom de macros" : orthographe.

"sizeof qui est une expression renvoyant une valeur" : sizeof n'est pas une expression.

"DEBUG&D_LOAD" : le code proposé en exemple ne respecte même pas la norme qu'ii est censé illustrer.

Franchement il est assez choquant de voir du code pareil :

function	int_size()
{
  int		s;

  s = sizeof(int);
  return (s);
}

"return est une structure de contrôle du C" Ah bon ? cf. Braquelaire, page 177 pour savoir ce qu'est une structure de controle en C.

" exit(1);" incorrect, bug potentiel, lire la norme du langage C.

"return prend un argument" formulation incorrecte, le terme d'"argument" s'emploie pour une fonction, return n'est pas une fonction ni un opérateur, return est une instruction.

"passez un pointeur sur cette structure (et jamais la structure directement)." abusif : il existe des situations (certaines récursivité) où on a besoin de garder des valeurs dans la pile et pour lesquelles on a besoin de passer la structure en argument et non un pointeur vers cette structure.

"Le symbole de pointeur (*)" fallait le dire ça : déréférencement= symbole pointeur !
Sinon, c'est discutable, on parle bien du type int*.

"Opérateurs unaires. Pas d'espace. " : sizeof est un opérateur unaire donc je dois écrire sizeoftoto ?

"Tous les opérateurs binaires et ternaires sont séparés des arguments": à nouveau, "argument" c'est pour des fonctions. Pour des opérateurs, on dit des "opérandes".

"Vous n'avez pas droit aux mots switch et for. " On n'a pas le droit d'utiliser for ? mais c'est quoi ce délire ?

"foo.c inclue toujours foo.h." : incluT


et encore je suis sur que j'ai pas tout vu.


Bref, pas sérieux, encore des gens qui ont soigné la cerise et négligé le gâteau (et ils ont pas trop d'excuses, ils en sont à la version 0.42).

Citation : candide

On n'a pas le droit d'utiliser for ? mais c'est quoi ce délire ?

Ceci a été décidé car certains en abusaient (du style faire un for de 80 caractères juste pour gagner des lignes)

Citation : joccd

Citation : candide

On n'a pas le droit d'utiliser for ? mais c'est quoi ce délire ?

Ceci a été décidé car certains en abusaient (du style faire un for de 80 caractères juste pour gagner des lignes)

Et parce que quelques hurluberlus font des for avec 80 caractères, plus personne ne peut utiliser l'instruction for ? Vous n'avez qu'à donner une taille maximale pour les 3 expressions du for.

Citation : joccd

Citation : candide

On n'a pas le droit d'utiliser for ? mais c'est quoi ce délire ?

Ceci a été décidé car certains en abusaient (du style faire un for de 80 caractères juste pour gagner des lignes)

Tu as un exemple concret d'abus, parce que là, j'ai du mal à voir l'usage de for peut-être abusif par rapport à l'utilisation d'une boucle de type while.

Thierry

for (foo(), bar(); barfoo() < foobar() && broo() == faar(); n++, i++, k += (i ? i-- : ++n))

Je suppose que c'est de ce genre d'abus dont il veut parler.

Citation : tc

Tu as un exemple concret d'abus, parce que là, j'ai dû mal à voir l'usage de for peut-être abusif par rapport à l'utilisation d'une boucle de type while.

Tu initialises 3 variables dans le premier champ, tu mets une condition à rallonge dans le deuxième et tout le traitement dans le troisième avec des ','.

Comme je dis, il y a 40.000 façons de se tirer une balle dans le pied en C. Mais c'est n'est pas en interdisant qu'on responsabilise...

Citation : -ed-

Citation : tc

Tu as un exemple concret d'abus, parce que là, j'ai dû mal à voir l'usage de for peut-être abusif par rapport à l'utilisation d'une boucle de type while.

Tu initialises 3 variables dans le premier champ, tu mets une condition à rallonge dans le deuxième et tout le traitement dans le troisième avec des ','.

Comme je dis, il y a 40.000 façons de se tirer une balle dans le pied en C. Mais c'est n'est pas en interdisant qu'on responsabilise...

Quelqu'un qui écrit ce genre de code ne fait pas beaucoup plus lisible avec une boucle while. Quant au reste du code...

Thierry

Citation : tc

Quelqu'un qui écrit ce genre de code ne fait pas beaucoup plus lisible avec une boucle while. Quant au reste du code...Thierry

tu t'écoutes quand tu parles écris ?

Citation : joccd

tu t'écoutes quand tu parles écris ?

?