[25] Standards de codage

Merci de lire cette réponse plutôt que d'essayer vos propres standards de codage.

Mais sachez que certains sur comp.lang.c++ sont très sensibles sur cette question. Quasiment tout ingénieur en informatique, à un moment ou un autre, a été employé par quelqu'un qui utilisait les standards de codage comme une sorte de "jeu". De plus certaines tentatives de créer des standards de codage pour le C++ on été faite par des gens qui ne savaient pas de quoi il parlait, aussi le standard de codage finissait par être basé sur ce qui était l'état de l'art quand le créateur du standard écrivait du code. De telles pratiques ont généré une attitude de méfiance vis-à-vis des standards de codage.

Evidement celui qui pose une telle question demande a être dirigé pour ne pas être entraîné par sa propre ignorance, mais poser une question de ce type à comp.lang.c++ a tendance a générer plus de bruit que de lumière.

Des standards de codage ne peuvent pas transformer un programmeur non Orienté Objet en un programmeur Orienté Objet; seul l'entraînement et l'expérience le peuvent. Si les standards de codage ont un mérite, c'est celui de décourager la désorganisation qui apparaît quand de grandes organisations coordonnent le travail de divers groupes de programmeurs.

Mais vous avez vraiment besoin de plus qu'un simple standard de codage. La structure fournit par un standard de codage donne au débutant un degré de liberté moindre pour le harceler sur ce qui est bon. Toutefois le pragmatisme devrait l'emporter sur des standards de codage fait pour avoir du "joli" code. Les organisations on besoin d'une philosophie de la conception et de l'implémentation cohérente. E.g., typage fort ou faible? références ou pointeur dans les interfaces? flux C++ ou flux stdio? Du code C++ peut-il appelé du code C? vice versa? Comment les ABCs doivent-elles être utilisés? L'héritage doit-il être utilisé comme une technique d'implémentation ou de spécification? Quelle stratégie de test devrait être utilisée? Stratégie de vérification? Les interfaces devraient elles avoir uniformément des fonctions membres get() et/ou set() pour chaque membre donné? Les interfaces doivent elle être conçus par une conception ascendante ou descendante? Les erreurs doivent-elles être gérées par des try/catch/throw ou par des valeurs de retours des fonctions? etc.

Ce qui est nécessaire est un "pseudo standard" pour détailler la conception. Je recommande une triple approche pour créer ce standard: entraînement, le choix d'un mentor , et les librairies. L'entraînement fournit une "instruction profonde", le choix d'un mentor permet a l'Orienté objet d'être ressentie plutôt que simplement appris, et des librairies C++ de classe fournissent "l'instruction a long terme". Il y a un marché commercial profitable pour ces trois sortes d'entraînement."Etre conseillé par des organisations qui en sont passé par la est consistent: Achetez, ne construisez pas. Achetez les librairies, l'entraînement, les outils, les conseils. Les sociétés qui ont tenté de faire du conseil aussi bien que des applications et des outils systèmes on trouvé le succès difficile.

Peu de gens argumentent qu'un standard de codage est "idéal," ou même "bon," toutefois ils sont nécessaires dans les organisations/situations décrites ci-dessus.

Les FAQs suivantes fournissent quelques idées basiques sur les conventions et et les styles.

Non!

Quelque soit votre expérience en C, quelque soit votre expertise du C, être un bon programmeur C ne fait pas de vous un bon programmeur C++. Convertir du C en C++ est plus qu'apprendre simplement la syntaxe et la sémantique de la portion ++ du C++. Les sociétés qui veulent obtenir les promesses de l'Orienté Objet, mais qui échoue à transformer l'Orienté Objet" en "programmation Orienté Objet", se mentent à elle-même; la balance commercial leur montrera leur folie.

Les standards de codage C++ devraient être modérés par des experts en C++. Demandez sur comp.lang.c++ est un début. Cherchez des experts qui peuvent vous évitez de tombez dans des pièges. Entraînez vous. Achetez des libraires et regardez si de "bonnes" libraires adhère a vos standards. ne faites pas de standards vous même a moins que vous n'ayez une expérience du C++ considérable. Ne pas avoir de standard est meilleur que d'en avoir un mauvais, car une position "officielle" impropre "endurcit" les mauvais traits d'esprits. Il y a un marché profitable provenant de l'entraînement et des libraires pour qui veut accumuler de l'expérience.

Une chose de plus: quand il y a de la demande, le nombre de charlatans augmente. Regarder avant de faire le saut. Cherchez aussi une étude critique de ces sociétés, car l'expertise ne fait pas nécessairement un bon enseignant. Finalement sélectionnez un praticien qui peut peut enseigner, et non pas une enseignant à plein temps qui n'aura qu'une connaissance passable du langage et de ces paradigmes.

[récemment crée merci a Stan Brown (on 1/00). "chaînage" des modifications récentes .]

Les fichiers entête dans le standard ISO C++ n'ont pas de suffixe .h. Ceci est une modification des pratiques précédentes. Certains détails changent entre les fichiers entête qui existaient en C et les fichiers entête qui sont spécifiques au C++.

La librairie standard C++ garantit avoir 18 fichiers entête qui proviennent du langage C. Ils sont fournit en deux variantes, <cxxx> et <xxx.h> (ou xxx est le nom de fichier sans extension, tel que stdio, stdlib, etc.). Ces deux variantes sont identiques excepté que les fichiers entête <cxxx> fournissent leur déclarations dans le namespace (espace de nom) std seulement, et les fichiers entête <xyz.h> fournissent les déclarations dans le namespace std et dans le namespace global. Le comité de normalisation a fait ceci de façon a ce que du code existant en C puisse continuer a être compilé en C++, toutefois les variantes <xyz.h> sont dépréciées, ce qui signifie qu'elles sont dans le standard actuellement mais qu'elles pourraient ne plus en faire partie dans l'avenir. (Voir ISO clause D et sous clause D.5 du Standard ISO C++ .)

La librairie C++ standard contient 32 fichiers entête additionnels qui n'ont pas de contrepartie en C, tel que <iostream>, <string>, et <new>. Vous pouvez voir des choses tel que #include <iostream.h> dans du vieux code, et des vendeurs de compilateurs offre des versions .h des entête de la librairie standard pour cette raison. Mais attention: les variantes .h, si elles sont disponible, peuvent différer des versions standards. Et si vous compilez des unités d'un programme avec, par exemple <iostream> et d'autres avec <iostream.h>, le programme peut ne pas fonctionner.

Pour les nouveaux projets, utilisez seulement les variantes <xxx> des fichiers entête, et pas les variantes <xxx.h>.

Quand vous modifiez ou étendez du code existant qui utilise les anciens noms de fichiers entête, vous devrez probablement suivre cette pratique a moins que des raisons importantes vous pousse à utiliser le nouveau style d'en-tête (telle que des facilités présentes dans le standard <iostream> et qui ne sont pas disponibles dans le <iostream.h> du vendeur). Si vous avez besoin de standardiser du code existant, assurez vous de changer les noms des entêtes C++ dans toutes les unités du programme et aussi dans toutes les libraires externes qui seront liées dans l'exécutable final (N.D.T. que ce soit des librairies statique ou dynamique).

Tout ceci n'a d'effet que sur les fichiers entêtes standards. Vous êtes libres de nommer vos propres fichiers entêtes comme vous l'entendez; voir [25.8].

Non, mais pas toujours, souvenez vous que la lisibilité est une des choses les plus importantes.

Certains pensent que l'opérateur ternaire ?: doit être évité car il est plus confus que la bonne vieille instruction if. Dans beaucoup de cas ?: tend a rendre le code plus difficilement lisible (aussi vous devriez remplacer les utilisations de ?: par une instruction if, mais il y a des cas ou l'opérateur ?: est plus clair car il peut accentuer ce qui est réellement fait, plutôt que le fait qu'il y ait un if (N.D.T. i.e. une décision de prise).

Commençons avec un cas simple. Supposons que vous voulez imprimer le résultat d'une fonction. Dans ce cas vous devez mettre le but réel (imprimer) au début de la ligne, et enterrer l'appel de fonction a l'intérieur de la ligne car l'appel de fonction a peu d'incidence sur le fonctionnement du code (Cette approche gauche-droite est basée sur la notion intuitive que la plupart des développeurs pense que la chose la plus importante sur une ligne de code est à gauche de la ligne) (N.D.T. le sens de lecture en occident est de gauche vers la droite ==> l'attention d'un lecteur se porte vers la partie gauche du texte d'abord) :

// Préféré (accentue le but majeur - imprimer):
cout << funct();

// moins bon (accentue le but mineur - un appel de fonction):
functAndPrintOn(cout);

Maintenant étendons cette idée a l'opérateur ?:. Supposons que votre but soir d'imprimer quelque chose, mais vous avez besoin de prendre une décision sur ce qui doit être imprimé. Etant donné que l'impression est la plus importante chose conceptuellement, nous préférons le mettre au début de la ligne, et nous préférons enterrer la logique de la décision. Dans l'exemple ci dessous, la variable e représente le nombre d'expéditeurs du message; le message lui-même est imprimé dans cout:

int n = /*...*/; // nombre d' expéditeurs

// Préféré (accentue le but majeur - imprimer):
cout << "Svp " << (n==1 ? "renvoie" : "renvoyez") << " le vite !\n";

// pas aussi bon (accentue le but mineur - une décision):
cout << "Svp ";
if (n==1)
cout << "renvoie";
else
cout << "renvoyez";
cout << " le vite !\n";

Comme je le disais, vous pouvez obtenir du code atroce et illisible ("du code en lecture seul") en utilisant des combinaisons variés de ?:, &&, ||, etc. Par exemple,

// Préféré (signification trivial):
if (f())
g();

// pas aussi bon (difficile à comprendre):
f() && g();

Personnellement je pense que le if explicite dans ce cas est bon car il accentue le but majeur (une décision basé sur le résultat de l'appel de f()) plutôt que sur le but mineur (appelé f()). En d'autres termes, l'utilisation de if est bonne précisément pour les mêmes raisons qui rendait son utilisation mauvaise dans le 1er exemple: nous voulons accentuer les choses majeurs et diminuer les choses mineurs.

Dans tous les cas n'oubliez pas que la lisibilité est le but (ou au moins un des buts). Votre but n'est pas d'éviter l'utilisation de certaine construction syntaxique tel que ?: ou && ou || ou if - ou même goto. Si vous tombez au niveau d'un "fanatique des standards," vous vous gênerez vous-même car il y a toujours un contre-exemple à toute règle basée sur la syntaxe. Si d'un autre coté vous accentuez les buts généraux et les principes directeurs (E.g., "accentuer les choses importantes," ou "mettez les choses les plus importantes en début de ligne," ou même "soyez sûr que votre code est trivial et lisible"), vous obtiendrez de meilleurs résultats.

Le code doit être écrit pour être lu, non pas par un compilateur, mais par un autre être humain.

Déclarez les prés de leur première utilisation.

Un objet est initialisé (construit) au moment ou il est déclaré. Si vous n'avez pas assez d'information pour initialiser un objet avant la moitié de la fonction, vous devriez déclarer celui-ci au moment ou il peut être correctement initialisé. Ne les initialisez pas à des valeurs "vides" au début de la fonction pour les "affecter" plus tard. Ceci pour une question de performance. Construire un objet correctement est plus rapide que de construire incorrectement puis de le remodeler plus tard. Des exemples simples montre un surcoût de l'ordre de 350% pour un classe telle que String. Cette ordre de grandeur peut varier; il est probable que le surcoût sera plus petit que 350%, mais il y aura un dégradation des performances. Une dégradation inutile.

Une riposte commune a ceci est: "nous fournissons des fonctions membres en écriture set() pour chacun des membres données de nos objets; aussi le coût de construction sera dispersé." Ceci est encore pire que le surcoût de performance, car vous avez introduit un cauchemar de maintenance. fournir des fonctions membre d'accès (set()) pour chaque données membres est équivalent a rendre public toute vos données: vous avez exposé votre implémentation au monde. La seule chose que vous ayez caché est le nom physique des données membres, mais le fait que vous utilisiez une List et une String et un float, par exemple, est ouvert au regard.

Les variables locales devrait être déclaré près de leur première utilisation. Désolé ceci peut être déroutant pour les experts du C, mais nouveau ne signifie pas nécessairement mauvais.

Si vous avez déjà une convention, utilisez la. Sinon, consultez la documentation de votre compilateur pour voir ce qu'il attend. Des réponses typiques sont: .C, .cc, .cpp, ou .cxx(naturellement les extensions .Cextension présumes que votre système de fichiers est sensible a la casse pour pouvoir distinguer .Cde .c).

Nous utilisons souvent .cpp pour nos sources C++, et nous avons aussi utilisé .C. Dans le dernier cas, nous fournissons au compilateur une option pour forcer les fichiers .c a être compilé en C++ (-Tdp pour IBM CSet++, -cpp pour Zortech C++, -P pour Borland C++, etc.) quand nous utilisons un système de fichier non sensible a la casse. Aucune de ces approches ne sont techniquement supérieurs aux autres; nous préférons généralement utilisé la technique qui est préféré par notre client (A nouveau, ces résultats sont dominés par des considérations commercial, pas par des considérations techniques).

Oui, Il y a des pratiques qui sont considérées comme généralement dangereuses. Toutefois aucune de ces pratiques n'est universellement "mauvaise" car des situations peuvent toujours apparaître ou ce qui est mauvais peut être nécessaire:

un opérateur d'affectation d'une classe Fred devrait retourner *this (i.e. un Fred&), permettant ainsi le chaînage des affectations
Une classe avec (au moins) une fonction virtuel devrait avoir un destructeur virtuel
Une classe avec une des fonctions membres {destructeur, opérateur d'affectation, constructeur par copie} devrait généralement avoir besoin des trois
Une class Fred avec un opérateur d'affectation et/ou un constructeur par copie devrait prendre des paramètres const: respectivement Fred::Fred(const Fred&) et Fred& Fred::operator= (const Fred&)
Quand vous initialisez les données membres d'un objet, utilisez toujours une liste d'initialisation plutôt que des affectations. Le surcoût en performance peut-être substantiel (x3!)
Les opérateur d'affectation devrait s'assurer que l' auto-affectation ne fait rien, autrement vous risqué un désastre . Dans certain cas, ceci peut nécessiter d'ajouter un test explicite dans votre opérateur d'affectation .
Dans les classe qui définissent les opérateurs += et +, a += b et a = a + b doivent généralement faire la même chose; idem pour les autres formules vrai pour les types de bases (E.g., a += 1 et ++a; p[i] et *(p+i); etc.). Ceci peut être assuré en écrivant les opérations binaires à partir des opérations op= forms. E.g.,
Fred operator+ (const Fred& a, const Fred& b)
{
Fred ans = a;
ans += b;
return ans;
}

De cette façon les opérateurs binaires "constructeurs" n'ont pas besoin d'être déclaré friends . Mais parfois il peut être plus efficace d'implémenter les opérateurs binaires directement (E.g., si la class Fred est une String, et si += a besoin de réallouer/copier la mémoire occupé par la chaîne, il peut être plus efficace, de connaître la longueur de la chaîne a priori pour éviter des allocations/copies inutiles).

C'est une histoire de tradition. Si vous avez un arrière-plan Pascal ou Smalltalk, vousUtiliserzProbablementDesNomscomme cela. Si vous avez un arrière-plan Ada, Vous_Utiliserez_Probabement_Un_Grand_Nombre_De_souligné. Si vous avez un arrière-plan Windows, vous préférez le notation "Hongroise" qui signifie pszPrefixéx ulLes bIdentificateurs dwAvec pvLeur pscType. Les utilisateurs d'Unix en C utilise svent des abbrév(N.D.T. plus vraiment d'actualité, une convention souvent utilisée sous unix est peu_importe_la_longueur),. ET LES PRGMRS FRTRAN LIMIT LEURS IDENTIF A SIX LETTRS.

Ainsi il n'y a pas de standard de codage universel. Si votre société a déjà un standard de codage, utilisez le. Mais démarrer un nouveau Djihad a propos des standards de codage génèrent plus d'obscurité que de lumière. D'un point de vue commercial, il y a seulement deux choses qui ont de l'importance: Le code doit être lisible, et tout le monde dans la société doit utiliser le même style.

A part ceci, ls difs snt minr.

[25] Standards de codage

Les FAQs de la section [25]