Règle de codage

[invitea4a9cbca]

Bonjour
J'aimerai bien savoir s'il y a un lien, en français, qui résume les règles de codage en C.
Merci d'avance
-----

[invite1c6b0acc]

Bonjour,
Avant de me risquer à répondre, tu veux dire les règles de syntaxe du C ou les règles de "bonne pratique" qu'il est souhaitable d'observer (et qui ne sont pas vraiment spécifiques à un langage) ?

[invitea4a9cbca]

Bonjour,
Avant de me risquer à répondre, tu veux dire les règles de syntaxe du C ou les règles de "bonne pratique" qu'il est souhaitable d'observer (et qui ne sont pas vraiment spécifiques à un langage) ?

les règles de "bonne pratique" : comment choisir les noms des variables, des fonctions ....

[Jack]

Avec l'autocompletion que l'on retrouve sur tous les bons éditeurs, il ne faut pas hésiter à choisir des noms parlants, quite à ce qu'il soient très long.

Un nom bien choisi évite des commentaires à ralonge.

[A voir en vidéo sur Futura]

[Jack]

Des informations bien utiles ici:
http://fr.wikipedia.org/wiki/R%C3%A8gles_de_codage

[invite1c6b0acc]

Bonjour,
Il n'est pas facile de définir des règles de codage toujours valables. Et chacun a sa propre perception ...
En ce qui me concerne, je considère que c'est la lisibilité du programme qui prime. Et déjà, ça dépendra beaucoup du lecteur.
Je pars du principe qu'un programme est bien écrit s'il peut être lu par un imbécile qui connaît à peine les rudiments du langage et qui ignore tout du problème traité. Et je suis bien content quand je réussis un peu, vu que 99 fois sur 100, l'imbécile qui va lire mon programme quelques années plus tard, c'est moi.

J'avais vu un jour (c'étais il y a longtemps et je n'ai pas gardé la référence) une page web où on expliquait des règles en les mettant à la forme négative. C'était très clair et ça avait beaucoup moins de chance de vexer quelqu'un.
La question devenait donc : "comment programmer le plus mal possible ?"

Et les réponses :
- utiliser des noms de variables ayant le moins de rapport possible avec le contenu de la variable.
- privilégier les abréviations obscures pour raccourcir les noms de variables (par exemple ndp plutôt que nombre_de_points)
- mélanger plusieurs règles quand à la casse (majuscules/minuscules) des noms de variables et de constantes
- indenter de façon irrégulière et changer de style d'indentation au cours du programme.
- éviter tout commentaire, ou alors veiller à ce qu'ils ne décrivent pas ce que fait le programme
- utiliser des astuces obscures pour gagner du temps ou de la place mémoire, surtout si le gain est négligeable
- structurer le programme de la façon la plus compliquée possible, avec le plus grand niveau de blocs imbriqués et en se servant au maximum de break et de goto
- utiliser plusieurs variables pour stocker la même données, et inversement stocker successivement plusieurs informations différentes dans la même variable
- toujours supposer qu'un appel système (allocation, ouverture de fichier ...) réussit : ne pas tester le retour.
- disperser sans logique discernable les fonctions dans une multitude de fichiers sources
- utiliser au maximum les variables globales et d'une façon générale privilégier les variables ayant la plus grande portée possible

J'en oublie forcément beaucoup.
Si quelqu'un veut continuer ...

A+

[polo974]

Bonjour,

J'en oublie forcément beaucoup.
Si quelqu'un veut continuer ...

A+

Pour les variables globales, essayer de rester sur 1 (ou au maximum 2) caractère(s) et cela en minuscule.
Si vous n'utilisez pas une de ces variables globales dans une fonction, déclarez et utilisez quelques variables locales portant les mêmes noms.
Redéclarez les protos des fonctions, variables et structures externes ainsi que les #define associés dans chaque source où ils sont nécessaires.

Au suivant...

[Jack]

Au suivant...

Utilisez le moins de parenthèses possible dans les expressions car elles sont inutiles

[invite2d7144a7]

Bonjour,

Pas d'accord avec les noms courts, ni d'ailleurs les variables globales, dont on peut pratiquement toujours se passer, et qui sont à l'origine d'une multitude de bugs, généralement difficiles à retrouver, du fait même de la globalité.

Ni pour les parenthèses, qui, si elles sont parfois inutiles, en raison de la priorité des opérateurs, évitent de passer du temps à dépouiller ce que signifie l'expression, clarifient la lecture, et sont donc au contrairement particulièrement utiles, pour ne pas dire indispensables.

[Dlzlogic]

Au suivant...

- Lorsqu'on calcule une longue formule
1- surtout éviter de la scinder en plusieurs parties
2- éviter à tout prix de revenir à la ligne. Plus la ligne est longue, moins ça occupe de place.

Au suivant...

[Jack]

Bonjour,

Pas d'accord avec les noms courts, ni d'ailleurs les variables globales, dont on peut pratiquement toujours se passer, et qui sont à l'origine d'une multitude de bugs, généralement difficiles à retrouver, du fait même de la globalité.

Ni pour les parenthèses, qui, si elles sont parfois inutiles, en raison de la priorité des opérateurs, évitent de passer du temps à dépouiller ce que signifie l'expression, clarifient la lecture, et sont donc au contrairement particulièrement utiles, pour ne pas dire indispensables.

Rassure-moi whoami, tu es sûr d'avoir bien lu le post de chanur et sur lequel nous avons enchainé?

[invitefa15af9f]

Bonjour

Au suivant...

Structure de contrôle doit être suivie par un bloc placé entre des crochets.
Par exemple au lieu d'écrire :

while ( … ) ; //pas lisible

Il est préférable de rajouter un bloc vide :

while ( … ) 
{
/* No thing to do  */
}

Au suivant...

[Jack]

On ne sait plus trop s'il s'agit d'ironie ou non désormais. pour moi, je trouve que c'est plutôt une bonne pratique (même si je ne l'applique pas systématiquement)

[Dlzlogic]

On ne sait plus trop s'il s'agit d'ironie ou non désormais. pour moi, je trouve que c'est plutôt une bonne pratique (même si je ne l'applique pas systématiquement)

Oui, moi aussi (je crois que c'était pas de l'ironie).
Ceci me fait penser à la syntaxe du switch.
Un "case X:" est une adresse, tout à fait comparable à celle d'un goto, et elle a l'avantage d'être très structurée. Elle a un autre avantage : il peut y en avoir un très grand nombre sans que cela ralentisse l'exécution, contrairement au if ... else if ... etc.
Elle a un autre avantage caché : aucune déclaration n'est autorisée entre le case X: et la fin du bloc (break; ).
Il s'agit donc d'un cas où il faut éviter de mettre un bloc entre accolades intérieur au bloc "case", s'il n'est pas nécessaire : une déclaration illicite ne sera pas détectée.
Enfin, associé à un enum, cela permet d'écrire des fonctions très longues et qui restent parfaitement claires. Très efficace aussi si on utilise la technique de hachage.
(désolé, Polo, j'ai abandonné momentanément le ton de l'ironie )

[invite2d7144a7]

Bonjour,

Rassure-moi whoami, tu es sûr d'avoir bien lu le post de chanur et sur lequel nous avons enchainé?

Évidemment ...

... que je ne l'ai pas fait.