Création de standards - Page 2

sinon, kevin, une autre proposition?

car c vrai que c quand mm pratique mm si l'on peut facilement contourner ca par des autres noms ...

Kevin, moi je l'utilise naturellement dans certains de mes programmes java, parce que ca les rend bien plus lisible par exemple avec swing pour savoir ce que represente ls variable, d'un coup le source est bien plus clair, de plus quand j'ai ete a Saint-Gobain pour adapter un intranet a oracle qu'on avait créé en acces, je te dis qu'il nous ont filé un pavé de standarts dans la boite, et tu sais pourquoi? pour qu'on les suivent et appliquent a notre source pour le rndre lisible par tout programmeur de la boite plus facilement, bien sur on l'a fait qu'a moitié parce que le source etait trop long a modifier(on l'a fait que pour quelques sources , apres on en a eu marre), mais bon je trouve ca vachement util, quand tu le fais des le debut d'un projet...

Vaut mieux choisir des noms de variarbles representatives. Et eviter les noms obscurs.
Pas besoin de convetion. 100% d'accord avec toi, Kevin.

Kevin> c'est justement en mémoire de ce tyrcu chez MS que je proposais ça...
Y'en a peut-être qui n'aiment pas... mais moi je trouve que ça facilite la compréhsension...

Natruellement, il faut que le reste du nom soit évocateur !
mais là, ça reste du domaine du programeur je penses...


constantes en maj => obligé

Certains préfèrent avec l'ajout. Autant que tou le monde puisse s'y retrouver, quitte à s'embêter un peu!!
Du moment que c'est clair aussi et explicite comme nom...

Ca me gave de rajouter 4 lettres a chaque variables. a la rigueur seulement pour les vars globales.

heu... en C, il est pluitôt rare d'utiliser des variables globales...

Et vous faites quoi quand vous avez une variable intToto et qu'après vous vous rendez compte que vous avez besoin d'un unsigned long long pour stocker toutes les valeurs qu'elle peut prendre? Remplacer partout intToto par ullToto? C'est tellement plus simple quand il suffit de changer int toto; en unsigned long long toto;.

remplacer partout, c loin d'être dur !
Option>remplacer, ou quelque chose comme ça dans tous les éditeurs de texte !

et il est assez rare de devoir changer ainsi (ou alors, la personne a qui ça arrive tout le temps n'a pas vraiment réfléchi sur son algo, et sur le fonctionnement de son prog)
(ne le prend pas personnellement mal !

OxmAn a écrit :
n'empeche c'est pratique quand ta un gros programme Kevin...

ta fait un sondage sur combien de programmeur mondiaux pour savoir qu'ils ont horreur de ca ?.

Voilà ce qu'en dit Linus Torvalds. Et il n'est pas le seul.

Ceci dit, je ne suis pas d'accord avec tous ses standards. (Cf. post 41.)

"Global variables (to be used only if you really need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that "count_active_users()" or similar, you should not call it "cntusr()".
Ben, il a pas tord !!! et je suis d'accord avec lui sur ce point.

pour le reste, je le suis moins.

En effet, moi aussi, je ne suis pas d'accord avec tout ce qu'il dit.

Personnellement, je trouve que:
- L'indentation doit être 1 caractère maximum. À la limite 2 si vous avez peur qu'on voie mal, mais 8 caractères d'indentation sont excessifs. Aussi devrait-on utiliser des espaces pour indenter, vu que les tabs font souvent 8 caractères
- Les { doivent toujours être en fin de ligne, même pour une fonction.
- Les petits blocs {} doivent être en une ligne. Par exemple:
if (x==1) {puts("Hello, World!")return;}
- Il ne faut pas mettre des espaces n'importe où. Par exemple:
x+1, pas x + 1
PortSet(0x4c00,239,127);, pas PortSet (0x4c00, 239, 127);
- Pour les noms de variables, je suis plus ou moins d'accord avec Linus (noms de variables locales courts, pas de notation hongroise), mais j'utiliserais plutôt la convention AMS pour les noms: DrawStr, pas draw_string.
- Pour les fonctions, j'aime bien les fonctions longues qui ne sont pas inutilement divisés en sous-fonctions, car le code devient plus optimisé: pas d'appels de fonctions inutiles, et possibilité pour l'optimiseur de travailler.
- Les commentaires doivent être dans une fonction, pas devant. Les commentaires qu'on met souvent devant une fonction seraient mieux placés dans un fichier "documentation utilisateur" séparé, et seulement s'il s'agit d'une librairie (et que donc les utilisateurs sont des programmeurs). Sinon, ce n'est pas la peine du tout.

Pr l'indentation, je suis d'accord avc toi : 2 charactères == nikel

Les { en fin de ligne... tu veux dire que tu préfére ceci :
void fonc{
...
}
à cela :
void fonc
{
...
}
Perso, je préfére la seconde solution.....

Les petis blocs en une ligne... ma fois, j'utilises les deux écriture. soit un ligne, soit plus. Ca dépend de la position dans le source, et de la complexité du passafge.

Pour les espaces, je les met afin de correspond aux ordres de priorité...
Je fait comme ça, en gros :
x = 10+5;
x = 10 + 5*6;
x = 10+5 - 3*6 + 2;
Et j'en met toujours dans les appels de fonctions, après chaque paramètre (et même, des fois, je reviens carément à la ligne entre chaque paramètres, si les paramètres font plus d'un écran de long)

Pour les fonctions, je préfre avec des "_", et le moins de majuscules possibles
(j'ai pas encore de vraie habitude là dessus... mais c en train de venir au fur et à mesure que je code KII... je verrai ce que ça donnera à la fin )

Pour les fonctions longues... ça dépend pr moi :
si c un truc qui est utilisé qu'un efois, je l'intégre. si c appelé plusieurs, je fais une autre fonction.

Pr les commentaries : je suis OK avec toi )

squale92
a écrit : Pr l'indentation, je suis d'accord avc toi : 2 charactères == nikel

Je préfère quand-même 1 caractère. Ça suffit pour faire voir que c'est indenté.

Les { en fin de ligne... tu veux dire que tu préfére ceci :
void fonc{
...
}
à cela :
void fonc
{
... }

Oui.

Plus précisément:
void func(int arg1, void *arg2) {
(Remarque qu'il y a des espaces après les virgules ici: c'est parce que c'est une déclaration, et qu'il y a nécessairement un espace entre int et arg1. Donc si je n'en mets pas après les virgules, ça devient assez déséquilibré: on a l'impression que le void * va avec arg1. Il y a aussi un espace entre ) et { pour la même raison.)

Perso, je préfére la seconde solution.....

Tu es libre de préférer ce que tu veux.

Pour les fonctions longues... ça dépend pr moi : si c un truc qui est utilisé qu'un efois, je l'intégre. si c appelé plusieurs, je fais une autre fonction.

C'est plus ou moins ce que je conseille de faire moi aussi. Les fonctions, ça sert pour ce qui est répété à plusieurs endroits. Ça ne sert à rien si c'est utilisé une seule fois.

OK.
(je répond court... mais OK pr tout le post

Kevin Kofler a écrit :
En effet, moi aussi, je ne suis pas d'accord avec tout ce qu'il dit.

Personnellement, je trouve que:
- L'indentation doit être 1 caractère maximum. À la limite 2 si vous avez peur qu'on voie mal, mais 8 caractères d'indentation sont excessifs. Aussi devrait-on utiliser des espaces pour indenter, vu que les tabs font souvent 8 caractères

J'aime bien 8 ou 4 perso. Mais bon je vais pas chipoter pour ca

- Les { doivent toujours être en fin de ligne, même pour une fonction.

Perso je les mets toujours sur une nouvelle ligne et re-indempte

- Les petits blocs {} doivent être en une ligne. Par exemple:
if (x==1) {puts("Hello, World!")return;}

Moi j'utilise une virgule dans ce cas la

- Il ne faut pas mettre des espaces n'importe où. Par exemple:
x+1, pas x + 1
PortSet(0x4c00,239,127);, pas PortSet (0x4c00, 239, 127);

Comme en francais, j'aime bien mettre un espace apres une virgule

- Pour les noms de variables, je suis plus ou moins d'accord avec Linus (noms de variables locales courts, pas de notation hongroise), mais j'utiliserais plutôt la convention AMS pour les noms: DrawStr, pas draw_string.

Ca roule pour moi a ce sujet.

- Pour les fonctions, j'aime bien les fonctions longues qui ne sont pas inutilement divisés en sous-fonctions, car le code devient plus optimisé: pas d'appels de fonctions inutiles, et possibilité pour l'optimiseur de travailler.

Ca depend de la taille. Pas plus de 50 lignes quand meme

- Les commentaires doivent être dans une fonction, pas devant. Les commentaires qu'on met souvent devant une fonction seraient mieux placés dans un fichier "documentation utilisateur" séparé, et seulement s'il s'agit d'une librairie (et que donc les utilisateurs sont des programmeurs). Sinon, ce n'est pas la peine du tout.

Bof, ca depend du commentaire.

Pour moi personellement:
-Indentation >
c'est plustot 2 ou 4 espaces: un c'est limite pour repérer au premier coup d'oeil(4 c'est ce que fait Emacs par défaut)

- Les { doivent toujours être en fin de ligne>
moi je préfère le :
[pre]void fonction(){ ... } Je vois pas l'itérêt de mettre une ligne avec juste un caractère si ca rends pas vraiment plus lisible, en plus du fait que quand on fait comme ca l'indentation auto d'Emacs prends trop de place -Les petits blocs {} doivent être en une ligne.> Ca dépends des cas mais quand il y en a plusieurs a la suite c'est vrai que c'est plus lisible - Il ne faut pas mettre des espaces n'importe où:PortSet(0x4c00,239,127);, pas PortSet (0x4c00, 239, 127); Certes mais quand les lignes commencent a être un peu grosses, les espaces ca aide sourtout qu'une virgule c'est pas hypervisible - Pour les noms de variables> Mes variables locales dépacent rarement les 2 lettres, Mais c'est sur que les variables globales doivent avoir un nom clair - Pour les fonctions> idem de Pphd - Les commentaires doivent être dans une fonction > dans et devant a mon avis, une doc utilisateur c'est bien mais si ca rentre en quelque ligne je vois pas pourquoi s'embeter.