Folco (./1) :
Convient-t-il mieux d'écrire :
if (condition){
<du code>
}
ou
if (condition)
{
<du code>
}
La première solution, sauf pour les fonctions où on met le
{ dans une ligne à part. (Bonne vieille tradition K&R.) Pour les
else, on met
} else { tout en une ligne.
Vaut-il mieux déclarer toutes les variables en début de fonction, ou les déclarer quand on va en avoir réellement besoin (par exemple, si une variable donnée n'a d'utilité qu'à un petit endroit donné de la fonction)
C'est plus pratique de les déclarer quand tu vas en avoir réellement besoin, mais attention, les compilateurs ISO C90 classiques ne comprennent pas, ils ne permettent les déclarations qu'en début de bloc. (Cela dit, je ne vois pas pourquoi il faudrait continuer à supporter les compilateurs qui ne suivent toujours pas le standard d'il y a 10 années (le C99).)
Vaut-il mieux avoir des variables globales (que TIGCC fout dans des BSS, et j'aime pas ça), ou mieux vaut-il avoir une structure dans main() les contenant et passer un pointeur en argument aux fonctions qu'on appelle ? J'ai choisi cette solution. Je penche plus pour la seconde solution, ayant l'habitude d'avoir ces variables sur la pile en ASM, et ayant un registre d'adresse global pointant vers ce frame et permettant à toutes les fonctions de voir ces variables.
Le mieux, c'est de ne passer que les variables que la fonction utilise réellement, par valeur quand c'est possible, c'est beaucoup plus propre.
Pen^2 (./2) :
J'aime bien la dissymétrie autour de l'affectation ^^
C'est moche.
Perso, j'utilise peu d'espaces autour des opérateurs, la coloration syntaxique sert à ça.
Mais en C tu es forcé de les déclarer en début de portée (après l'accolade)
Pas en C99. GCC accepte les déclarations au milieu du code depuis la version 3.0.
Ximoon (./3) :
Bon, j'imagine que tu dois savoir qu'on ne peut pas déclarer de variable en plein milieu du code, mais seulement en début de bloc ? 
C'est faux, cf. ci-dessus.
Si tu parles de trucs du genre "for(int i =0; i<truc; i++)", je trouve ça horrible, et d'un moint de vue maintenance du code c'est du suicide.
Le C99 permet aussi ça, TIGCC permet ça avec
-std=gnu99 (que je vais peut-être mettre par défaut un de ces jours, du moins pour les nouveaux projets dans les EDIs) et j'utilise ça dans mon code. (Il y a aussi
-std=c99 pour le C99 strict, mais TIGCC ne supporte que les modes GNU.)
Zephyr (./8) :
- Accolades ouvrantes et fermantes seules sur leurs lignes, et indentées au même niveau (comme le 2eme exemple de Folco)
- Indentation avec des tabulations (souvent à 4 espaces), pas avec des espaces
- Déclaration des noms de variables et de fonctions alignées, avec une variable par ligne
- Espaces autour des opérateurs binaires, les assignations ne font pas exception : plop = array[i] + (5 * step);
- Espaces avant la parenthèse ouvrante des appels de fonction (je trouve illogique d'en mettre pour les mots-clés et pas pour les appels) : result = function (a, b);
- Astérisque (ou & pour le C++) collé au type et non à la variable (ça caractérise le type d'une variable, pas son nom) : int* a = &b- Blocs logiques dans le code séparés par une ligne vide
Bref, exactement le contraire de ce qu'il faut faire.
(Enfin, les lignes vides, ça passe de temps en temps, mais je ne les utilise que rarement.)
Je signale aussi que
int* a est une faute logique comme le prouve l'exemple
int* a, b qui ne fait pas ce que tu veux. Ta règle "une seule déclaration par ligne" n'est qu'un bidouillage pour traîter les symptomes de cette erreur de compréhension. L'étoile se rattache au
a en C.
Ximoon (./9)
Il y a beaucoup trop de commentaires et d'espace blanc dans ton exemple.
Sally (./10) :
edit : c'est beau les tab à trois espaces 
(par contre l'idéal c'est d'utiliser le caractère tab et de le régler visuellement à trois espaces, pas de taper les trois espaces ^^)
Et du coup, à moins que tu ne suives rigoureusement le style de Sebastian Reichelt (tab sous tab, espace sous autre caractère, un tab par niveau d'indentation, jamais de "compression" d'espaces par des tabs), ce que les éditeurs courants ne facilitent pas du tout, si le lecteur utilise une autre largeur de tabs, il va se retrouver avec du code aligné n'importe comment.
Les espaces, c'est mieux, c'est du WYSIWYG.
Ximoon (./13) :
et que tout compilateur ne respecte pas forcément la norme : j'ai déjà vu des char sur 16 bits
Il est possible d'avoir un
char sur 16 bits tout en respectant la norme. (Cela dit,
sizeof(char) == 2 n'est pas conforme, les machines avec des
char de plus de 8 bits sont les machines tordues où on ne peut pas adresser chaque octet et où l'unité de la machine est donc un entier plus long.)
Sasume (./14) :
Zephyr (./12) :
À propos de la deuxième remarque de Ximoon, je suppose que c'est pour pouvoir changer facilement un type de données (int 16 bits -> int 32 bits par exemple) dans le programme en modifiant juste un "typedef" dans un header.
Mais pourquoi serait-on amené à faire ça ? Quid de stdint.h et inttypes.h ?
C'est du C99, donc si on veut gérer les compilateurs préhistoriques qui se limitent au C90 (et il me semble que ce soit le cas de Ximoon), on ne peut pas les utiliser. De plus, TIGCC ne gèrera
stdint.h que dans la prochaine bêta (mais tu peux télécharger le header dans notre CVS si tu en as besoin maintenant) et nous n'avons pas encore de
inttypes.h (celui de GCC4TI est incomplet et la documentation est insuffisante).
Folco (./23) :
Ca vous arrive d'écrire :
if (condition) machin;
ou alors vous préférez :
if (condition)
machin;?
Le premier si ça tient en une ligne, la deuxième sinon (c'est mieux que de mettre un saut de ligne en plein milieu de
machin), et si ça ne tient toujours pas, ben:
if (condition)
machin(xxxxxxxxxxxxxxxxxxxxxxxxxxxxx,
chose); Zephyr (./26) :
Parceque si un mec passe derrière moi et qu'il a des goûts étranges (indenter avec une largeur de 3 caractères par exemple ^^), un code source avec des tabulation sera lisible pour lui (son éditeur affichera des tabulations avec la largeur qu'il aura configuré).
Justement non, comme dit plus haut, le code risque fort d'être le bordel chez lui sauf si tu as fait très attention à ce que tu fais. Et dans tous les cas, les indentations variables posent problème si tu veux fixer la largeur maximale de tes lignes (genre à 80 caractères, 120 caractères ou ce que tu veux), ce qui est une bonne idée pour éviter de devoir défiler horizontalement (
).
Sally (./27) :
Le comble de l'atrocité, c'est quand même l'indentation automatique d'emacs avec les options par défaut (Dieu merci ça se désactive, mais comment ont-ils pu 
er au point de seulement avoir l'idée de ce système pourri ? 
)
Pour ceux qui ne savent pas, ça mélange les tabs et les espaces 
, et donc c'est totalement dépendant de la largeur du tab, je crois que par défaut la tab vaut 8, donc au premier niveau d'indentation il insère deux espaces, au second quatre, au troisième six, et au quatrième... tab 
(et au cinquième tab+2 espaces etc.) Et comme c'est le mode par défaut, si t'es pas au courant...
Effectivement, c'est totalement foireux, ce système.
Malheureusement, c'est la convention GNU.
(C'est la seule idée de l'indentation K&R qu'ils ont retenue, manque de chance c'est la seule qui n'a aucun sens.
)
Lionel Debroux (./29) :
Par exemple, je pense que le 'if (cond) {' sur la même ligne est une question de goût. En revanche, le '} else {' ne me paraît pas bon pour la lisibilité (c'est moins facile de trouver le "else").
Mais on voit tout de suite qu'il y en a un quand on lit le code.
Au moins, ça empêche de faire le truc très moche, parce qu'impossible à porter entre des compilos différents et éventuellement entre des versions du même compilo (il me semble que ce n'est pas garanti par le standard, et heureusement ^^), qui consiste à utiliser la valeur d'une variable d'itération principale hors du corps de la boucle
En C:
int i;
for (i=0; i<10; i++);
printf("%d\n",i);est parfaitement défini et affiche toujours
10.
).
)
C'est moche.
(par contre l'idéal c'est d'utiliser le caractère tab et de le régler visuellement à trois espaces, pas de taper les trois espaces ^^)
er au point de seulement avoir l'idée de ce système pourri ? 
)
, et donc c'est totalement dépendant de la largeur du tab, je crois que par défaut la tab vaut 8, donc au premier niveau d'indentation il insère deux espaces, au second quatre, au troisième six, et au quatrième... tab 
(et au cinquième tab+2 espaces etc.) Et comme c'est le mode par défaut, si t'es pas au courant... 
).
)
