2009-10-28 3 views
4

Dans un code C, comment séparer différentes sections de code, par exemple Implémentation, Globals, etc? Y a-t-il une norme de codage? Je l'ai vu de nombreuses méthodes, mais que l'on est préféré, je veux obtenir des avis de la communauté sur ce ..C Mise en page de code et comment séparer les différentes sections de code?

/********************************************************* 
*      GLOBALS      * 
*********************************************************/ 

ou

/* 
* GLOBALS 
*/ 

Ou quelque chose de semblable?

EDIT: Permettez-moi de clarifier, je suis à la recherche de moyens préférés. Pas de normes en réalité. Qu'avez-vous vu dans les projets, ou avez-vous utilisé vous-même? Le deuxième point est que j'aime lire du code, et si quelque chose va vous aider à comprendre différentes sections tout en regardant le code à travers un écran de console limité, je l'ajouterais à la norme. La disposition du code est importante ainsi que ce qu'il fait. Ainsi, l'exigence numéro un est qu'un tel séparateur doit être facilement perceptible tout en faisant défiler le code source très rapidement, page par page.

+4

Si vous voulez des opinions de la communauté sur une question comme celle-ci, je pense que vous devriez faire de la communauté wiki alors ... – ChristopheD

Répondre

2

Ce genre de tronçonnage a tendance à être plus important pour les débutants que pour ceux expérimentés dans la lecture C. Il y a une structure de base solide pour la plupart des fichiers source C:

  • commentaire d'ouverture (projet et d'identification des fichiers, le droit d'auteur et licence, explication de base de ce qu'elle contient).

  • Fichiers d'en-tête, éventuellement aveC# define (pour choisir une version particulière de POSIX, par exemple).

  • Définitions de type local, macros, etc. Variables globales, si vous en avez.

  • Déclarations locales (variables, fonctions statiques).

  • Fonctions dans le fichier.

Il peut y avoir des variations, mais déclarant statique de fichier (ou, pire encore, les variables globales) en partie par le fichier est regardé comme une mauvaise pratique - idem en-têtes supplémentaires.

Mais il n'y a peut-être rien de formel séparant ces sections. Rappelez-vous que les commentaires de boîte sont plus difficiles à maintenir - mais les séparateurs de section changent rarement, donc il n'y a pas beaucoup à choisir entre eux. J'utiliserais probablement un commentaire d'une ligne pour séparer les globales de ce qui se passait avant - si j'utilisais quelque chose.

1

La norme est ce que vous définissez comme étant. La chose la plus importante est de définir une norme, puis respectez-le.

3

Il y a beaucoup d'arguments sur le style de code, en particulier sur C, en raison de sa flexibilité. Une grande liste d'options peut être trouvée here.

Le style du noyau linux et le style GNU sont assez courants. La chose la plus importante est que votre code soit cohérent, peu importe ce que vous faites. Cela vaut aussi pour modifier le code de quelqu'un d'autre - même si vous n'aimez pas les choix de style, vous devez respecter leurs règles pour faciliter la fusion et les modifications ultérieures.

3

Je n'ai jamais vraiment vu un point dans les commentaires de ce genre (un autre souvent vu est des en-têtes similaires pour les fonctions, qui n'ont rien d'autre que le nom de la fonction). Si vous avez besoin de trouver un identifiant particulier, indépendamment de ce que c'est, ctags - ou, mieux encore, un IDE décent, peut le faire pour vous. Quelle autre valeur a une telle organisation?

+0

+1, mais je pense que c'est un mauvais exemple. Il est plus probable qu'il s'agisse de regroupement - fonctions traitant de cela, fonctions traitant de cela, etc. –

0

Il n'existe pas de norme de codage communautaire en soi, à moins que la communauté dans laquelle vous vous trouvez en impose une. C'est à vous et/ou à votre équipe de prendre la décision quant à la norme que vous souhaitez adopter et de voir par vous-même celle que vous préférez.

Il existe cependant des standards que les programmeurs ont tendance à utiliser sans même s'en apercevoir. La plupart d'entre eux peuvent être trouvés sur ce (plutôt vieux) page.

1

J'utiliserais la deuxième version; C'est plus simple et plus facile à maintenir.

Questions connexes