Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les règles de codage C++ de Google : méconnaissance du langage ou principe de précaution ?

Le , par LittleWhite

0PARTAGES

1  0 
Bonjour,

J'écris un post, d'abord pour signaler la présence de ce document: http://google-styleguide.googlecode....k/cppguide.xml
Je m'excuse pour tout ce qui ne lise pas l'anglais ...

Je voudrais remarquer deux points assez interessant, vu que l'on en parle souvent sur ces forums:

- http://google-styleguide.googlecode....xml#Exceptions
We do not use C++ exceptions.
Nous n'utilisons pas les exceptions C++
- http://google-styleguide.googlecode....line_Functions
Define functions inline only when they are small, say, 10 lines or less.
Définissez les fonctions en inline lorsqu'elle sont petite, disons, 10 lignes ou moins.
Je vous laisse découvrir le reste

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de foetus
Expert éminent https://www.developpez.com
Le 29/06/2017 à 15:10
Citation Envoyé par Luc Hermitte Voir le message
2- on ne mélange pas tab et espace.
Si on peut le faire les tabulations c'est pour indenter (début de lignes - à gauche), et les espaces pour "l'ascii art" (en fin de lignes - à droite)

Exemple:
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
    var a    = 0;
    var a1   = 0;
    var a2   = 0;
    var b    = 0;
    var b01  = 0;
    var b02  = 0;
    var c    = 0;
    var c001 = 0;
    var c002 = 0;
3  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 30/06/2017 à 9:28
Citation Envoyé par foetus Voir le message
Si on peut le faire les tabulations c'est pour indenter (début de lignes - à gauche), et les espaces pour "l'ascii art" (en fin de lignes - à droite)
Tout a fait d'accord! J'avais chercher a repandre la bonne parole dans un blog il y a quelques mois: https://mickaelistria.wordpress.com/...bs-and-spaces/
L'air de rien ce debat est serieux, il concerne la lisibilite/portabilite du code et il contient des notions de models vs rendering qui sont importantes dans pas mal des domaines. Meme si je n'en ferais pas un critere de selection important en entretien d'embauche, je jetterai le pave dans la mare quand meme pour voir comment reagit la personne (si elle comprend deja la notion de model/rendering, si elle sait pourquoi des gens preferent 2-4-8 espaces pour une tab selon le type de fichier et l'editeur, si elle est ouverte a la discussion ou si elle est bornee en disant "Chez Google ils font comme ca, c'est que c'est mieux" sans presenter d'esprit critique, ...)

Citation Envoyé par Luc Hermitte Voir le message
Dans les faits il n'y a que emacs qui sache faire ça je crois. Du coup, ce n'est pas vraiment utilisable sur un projet où notepad++, emacs, eclipse, QtCreator sont chacun utilisés par une personne différente.
Tous les editeurs savent inserer une tab quand tu appuies sur tab, et un espace quand tu appuies sur espace... A un moment, c'est aussi au developpeur de se poser la bonne question sur 1. ce qu'il cherche a inserer et 2. ce que l'editeur insere effectivement.
Dans Eclipse IDE, je recommande a tous les utilisateurs avec lesquels j'ai l'occasion de passer du temps a code d'afficher les tabs/espaces avec des caracteres en gris clair ( http://help.eclipse.org/oxygen/topic...ditorprefs.htm > "Show whitespace characteres" ). Jusqu'ici j'ai pas eu de retour negatif sur cette pratique et j'ai eu quelques commentaires tres positifs du genre "ouah, c'est degueulasse! Je savais pas qu'on indentait si mal!"
3  0 
Avatar de Bktero
Modérateur https://www.developpez.com
Le 29/06/2017 à 15:21
Notez que les règles de codage de Google sont désormais ici : https://google.github.io/styleguide/cppguide.html

L'ASCII art c'est de la cr***e !
2  0 
Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 30/06/2017 à 10:24
Si c'est à la main que l'on indente en appuyant explicitement sur la touche tab puis des espaces pour aligner les lignes suivantes, on a perdu, et il faut changer d'outil ou apprendre à se servir de celui que l'on utilise. C'est à l'éditeur de prendre en charge cela. Dit autrement, il ne faut pas à avoir à appuyer sur tab, mais juste sur: "aller à une nouvelle ligne" (a.k.a. <entrée>, ou "réindente la(/es) ligne(s) courante(s)" (utile en cas de refactoring/import de code). Si on appuie explicitement sur <tab>, cela veut dire que la tâche de mise en conformité avec le style retenu pour le projet n'est pas automatisable.

NB: je ne fais pas référence au cas trivial de
Code : Sélectionner tout
1
2
<destabs>auto i   = 42;
<destabs>auto str = "toto"s;
Mais à celui de
Code : Sélectionner tout
1
2
3
<destabs>auto r   = expression(complexe)
<destabs>         + une(autre(expression * complexe)) // ici je veux bien que l'on intervienne pour aligner le + sur le =, et encore l'éditeur doit proposer de lui-même un retrait par défaut à défaut d'être intelligent
<destabs>         - une(dernière);                    // ici, l'indentation doit être automatique!

La difficulté arrive quand en début de ligne on commence par des tabulations pour indenter une fois par niveau d'imbrication, et autant de fois que nécessaire pour aligner avec la ligne précédente. Tous les outils ne savent pas détecter une continuation de la précédente expression et permettre d’enchaîner tabs puis espaces dans ce cas là, sans parler des développeurs qui pourraient utiliser notepad qu'ils ne verraient pas de différence dans leur process d'indentation.

C'est pour cela que pour le coup je prêche pour le nivellement par le bas, et que l'indentation intelligemment mixée... je n'y crois pas sur des équipes mixtes en termes d'environnements de développement, et en termes de profils de développeurs.

NB: pour montrer qu'ils indentent comme des pieds (/avec des outils mal paramétrés), je les envoie sur le portail web du gestionnaire de version, souvent les mélanges d'indentation y sont criants. En général, c'est la conséquence de projet qui impose d'indenter avec des espaces, et d'outils qui n'ont pas été configurés.

En ce qui me concerne, dans tous les cas, l'indentation (avec ou sans alignement supplémentaire) doit être automatisée : si on passe un outil sur le code, c'est l'outil qui a raison. A nous de bien configurer l'outil.
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 01/06/2010 à 20:28
Je ne pourrais pas être plus d'accord avec joel ou avec Goten...

Nous sommes tous bien conscients du fait que les règles de codages doivent exister, et qu'il faut "flinguer à vue" tout ce qui s'en écarte, que ce soit en terme de convention d'écriture / de "mise en forme" du code, de convention de nommage, de présentation de commentaires ou de tolérance à ce que j'appellerais les "sucres syntaxiques".

Si l'on souhaite que tout le monde puisse lire "aussi facilement que possible" le code de n'importe qui, si l'on veut éviter toute méprise, l'absolue nécessité des règles de codage ne fait strictement aucun doute.

Par contre, si les règles de codage rejettent des pans entiers du langage pour ce qui n'est généralement plus que des "légendes urbaines" (ou peu s'en faut), qu'elles ont pour résultat un "nivellement par le bas", ou d' "institutionnaliser" des approches qui rendent le développement plus compliqué que ce qu'il ne devrait être sans pour autant améliorer ( pour ne pas dire en diminuant) la qualité du code produit ou du développement, il faut aussi pouvoir débattre des points noirs et défendre son point de vue, avec l'espoir de faire évoluer les choses vers une meilleure situation.

Nous sommes tous conscients que ce n'est sans doute pas une personne seule qui arrivera à faire bouger la "montage bureaucratique" que peut représenter une société comme google (ou comme toute autre société utilisant des règles de codage aussi précise), mais, il ne faut pas oublier que ce sont les petits ruisseaux qui forment les grands fleuve: si ceux qui peuvent justifier de l'inopportunité d'une règle parlent "d'une même voix" et "tiennent le cap", elles ont malgré tout une chance d'atteindre et de convaincre quelqu'un qui pourra faire changer les choses.

Le lobbying a toujours existé et a souvent été utilisé, non
1  0 
Avatar de ac_wingless
Membre confirmé https://www.developpez.com
Le 07/06/2010 à 16:36
Désolé, mais vu ce sur quoi tourne la discussion, je pense qu'il faut un peu remettre en contexte les règles de codage et à quoi elles servent.

Support des outils.
Il n'y a pas que Visual Studio 10 / gcc 4.5 dans notre métier. Une proportion incalculable mais très élevée des projets C++ n'a pas un seul compilateur mais plusieurs, dont certains n'ont tout bêtement pas de support pour un tas d'éléments du C++ moderne, ou bien les supportent avec des petits tics incompatibles (comment vous portez du C++ moderne depuis x86 vers le dernier DSP? comment vous portez les codes avec constructeurs sur les architectures à mémoire fixe? comment vous "démanglez" entre deux puces de constructeurs différents? comment vous implémentez une fonction virtuelle sur GPU (merci Fermi!!!)? etc. ). En attendant, il faut livrer le code, parce que la programmation pure ne pèse pas forcément grand chose dans l'édifice: il y a des dizaines d'autres corps de métier qui ne se sentent pas concernés par les ergotages acronymiques C++iens. Comment dire au responsable du génie civil qui vient de couler 1300 tonnes de béton qu'il faut revenir l'année prochaine parce qu'on a eu un problème de régression de templates au passage de VS2008 à VS2010?

Pourquoi est-ce qu'on utilise encore le C dans l'embarqué? Parce que si on utilise le compilateur C++ disponible (s'il y en a un), on n'a pas de fiabilité avec les templates, tr1 et tout le tralala. Ce n'est parce que C serait plus adapté! Pourquoi on utilise l'assembleur? Parce dès fois qu'on n'a même pas C (je n'ai heureusement plus d'exemple en 2010, mais c'était encore vrai il y a peu, et cela le reste pour le support de projets allant de 3 à 25 ans d'age).

Donc les règles de codage ont une importance ABSOLUMENT CAPITALE dans la partie programmation des projets non purement informatiques: il est exclu de prendre le moindre risque pour des raisons de productivité de ce qui n'est qu'une portion du système, si importante qu'elle nous paraisse. Discuter de nivellement par le bas ou par le haut du point de vue du programmeur est donc HORS SUJET: on nivelle au niveau des outils disponibles, qui se trouve être bas par définition, puisqu'il n'est matériellement pas possible d'être à la pointe de la productivité dans des projets d'envergure ne serait-ce que par leur durée significative et leur étendue de domaine.
Tant pis pour la productivité de l'équipe informatique, les autres corps de métier en font autant dans leur domaine de toute façon.

En déduire un peu rapidement que "des grosses boites font des choses qui peuvent ne pas être bonnes", ou que les développeurs impliqués "n'aiment pas le C++ moderne" est désobligeant, et heureusement sans fondement. Une bonne partie des innovations et du C++ moderne vient aussi de ces grosses sociétés ayant en place des règles de codage nivelant par le bas. Outre les exemples passés (C++ est né dans un labo d'une grosse boite...), on peut parier qu'à l'avenir les divers outils nécessités par l'industrie continuent d'enrichir le standard. Par exemple, je pratique de plus en plus des règles de codage intégrant un mécanisme permettant d'obtenir des "exceptions déterministes". Comme indiqué dans mon post précédent, les exceptions au sens C++ sont interdites dans nombre de projets industriels pour de très bonnes raisons. Cependant, l'intérêt des exceptions n'échappe pas à ces benêts aux commandes dans les grosses boites...

Fiabilité interne et externe
Je sais pas avec quelles équipes vous tournez, mais en ce qui me concerne, même si je pense avoir une équipe du tonnerre avec qui on a pu sortir des projets incroyables qui ont laissé nos partenaires et clients stupéfaits, on a tous des jours sans, des problèmes de gamins à garder, des vacances à prendre, et puis ça reste un métier, pas une art ou une croisade. Certains d'entre nous ont bien plus de 25 ans. Si, si, je sais c'est dur à croire mais c'est vrai.
Dans ces conditions, il n'est pas toujours possible de demander à toute l'équipe, à des stagiaires, à des intérimaires, voire aux sous-traitants ou intervenants extérieurs d'adopter des mêmes pratiques de codage évangélistes, quelles que soient les qualités de ces pratiques. Une règle de codage prend en compte la réalité qui fait qu'une équipe n'est pas homogène. Dans ce cas se pose la question du niveau à cibler, une fois pris en compte le principal ci-dessus (le niveau proposé par les outils): vers le bas, ou vers le haut? Et pourquoi pas viser juste?

Dans bien des projets, il faut accepter que des intervenants non payés suffisamment n'auront pas la motivation, la formation ou la compétence de mettre en œuvre des méthodes sophistiquées.
Même pour du personnel de très haut niveau ultra-bien payé, des problèmes d'un autre ordre se posent: il faut aussi réaliser que dans certains pays, les relations programmeur / employeur sont des rapports de force sans pitié ni état d'âme... dans les deux sens. Je ne vais pas rentrer dans les détails, mais ceux qui ont travaillé aux USA savent de quoi je parle, et plus encore ceux qui ont employé des programmeurs dans un environnement par exemple texan.

Pour maitriser ces phénomènes, il faut donc viser un niveau qui tienne compte à la fois de la productivité et de la maitrise du projet (vu du point de vue de la grosse boite, pas de celui du chef de projet). Bien évidemment, ce niveau en question n'a aucune raison de coïncider avec ce qu'un programmeur individuel ou habitué a de petites équipes se croit en droit d'espérer.

Inertia or momentum?
Si on fait abstraction des deux points évoqués ci-dessus (nivellement par les outils et par l'équipe), et qu'on se place dans un cas idéal: disons, deux ou trois personnes motivées démarrent un projet open source sans but lucratif, sous environnement VC10 / Boost 1.43 avec des PC de fous, sans date limite. Quelles vont-être les règles de codage? On voit d'après cette discussion qu'il va y avoir un peu de bagarre sur des points de détail. On peut aussi prédire des changements assez fréquents. On peut enfin être certain que les règles en question vont être bien plus "évoluées" que celles des projets industriels significatifs.
Par contre on voit aussi tout de suite à quel point c'est impossible à mettre en place dans une structure de grande taille, même à supposer une homogénéité et une qualité exceptionnelle de l'équipe. Imaginons des règles de codage démocratiques chez la R&D Thales, juste pour rire!
Être à la pointe des recherches en productivité a pour contrepartie obligatoire l'impossibilité d'avoir fait ses preuves sur la durée. On en revient aux grands classiques: quel équilibre entre la réactivité et la stabilité? C'est un problème presque culturel et n'ayant pas de solution tranchée.
(petit hors sujet pour montrer l'universalité de la question: doit-on virer la moitié du personnel dans les mauvaises années et rater le redémarrage, comme Boeing, ou bien tenir son cap coute que coute, et foncer dans le mur comme Airbus réalisant deux ans trop tard ses problèmes d'assemblage de l'A380?)

Productivité globale
Alors on a défini un niveau de programmation selon les outils, les intervenants, et on a choisi un niveau de réactivité. Il reste un paramètre: l'arbitrage entre l'assurance qualité et la programmation. Il est clair que les couts d'assurance qualité vont baisser si le code est facile à contrôler automatiquement, ce qui ne se fait aujourd'hui qu'avec des règles de codages simples.
On a un effet pervers à l'œuvre: en simplifiant la palette utilisable en programmation, on facilite le travail du contrôleur de la qualité sans assurer une meilleure qualité, bien au contraire. Tout en perdant de la productivité!

Mais là encore, tout n'est pas aussi simple: si on ne met pas en place des règles strictes et enforçables, on s'expose à des catastrophes, et comme on est dans le cadre de grosses boites voyant défiler des nuées de programmeurs, la loi de la Tartine s'applique. Alors que faire? Pour voir, prenez une feuille blanche, et remplissez là. Relisez bien le résultat. Allez voir votre responsable QA et votre directeur régional. Séchez vos larmes, et recommencez...

Conclusion
Les règles de codage ont ceci comme avantage qu'elles ont une vue bien plus ambitieuse de la fiabilité que la myopie focalisée sur le code seul: elles établissent, et valident dans des cas difficiles, des pratiques globales, pragmatiques et débarrassées de tout évangélisme plus ou moins durable. Elles prennent en compte localement (projet ou entreprise) l'environnement industriel, économique, voire sociologique et culturel de la programmation.
Dans tous les cas que j'ai vu, les règles de codages ne sont pas pondues par un stagiaire après coup, mais sont au contraire extrêmement bien réfléchies, raffinées au cours des années, avec des rationalisations élaborées sur pratiquement tous les points (à ce propos, le document de Google cité au départ me semble beaucoup moins élaboré que les règles de codage d'autres grandes entreprises, comme je le disais dans mon post précédent).

Comme ces règles sont en général beaucoup moins permissives que celles de Google, tout en ayant fait leurs preuves sur des projets parfois remarquables, je suis un peu estomaqué de voire l'arrogance avec laquelle elles sont considérées dans cette discussion. Je n'ai pas encore lu le principe de Peter, mais on dirait que ça vient...
Et si en fait les professionnels ayant pondu ces documents savaient en fait de quoi ils parlent, avaient pesé le pour et le contre à la lumière de projets réels, et pris des décisions éclairées?
1  0 
Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 29/06/2017 à 14:40
En matière d'indentation, il y a deux règles, valables partout:
1- on indente sous les structures de contrôles, et dans les définitions (struct & co, fonctions...)
2- on ne mélange pas tab et espace.

Après tab ou espace, chacun a des arguments pour l'un ou pour l'autre. Mais souvent, il s'agit de mélanger des outils qui ne sont pas configurés pareil, voire pas configurés.

Pour le reste, c'est toujours la problématique que des gens veulent un style uniforme partout. Certains sont très rigides là dessus, et il ne s'agit pas toujours des premiers concernés (i.e. les développeurs).

Et vu qu'il s'agit d'un déterrage, on peut dire que depuis les CppCoreguidelines sont sorties et qu'elles méritent d'être employées pour dépoussiérer bien des choses que l'on utilise.
2  1 
Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 29/06/2017 à 16:48
Citation Envoyé par foetus Voir le message
Si on peut le faire les tabulations c'est pour indenter (début de lignes - à gauche), et les espaces pour "l'ascii art" (en fin de lignes - à droite)
Effectivement, c'est la seule façon intelligente de les mixer.

Dans les faits il n'y a que emacs qui sache faire ça je crois. Du coup, ce n'est pas vraiment utilisable sur un projet où notepad++, emacs, eclipse, QtCreator sont chacun utilisés par une personne différente.
1  0 
Avatar de Goten
Membre chevronné https://www.developpez.com
Le 05/05/2010 à 22:15
Pour les exceptions je trouve leur arguments contre l'utilisation des exceptions pas très... justifiable.

Je vois qu'ils utilisent les API de type printf plutôt que les flux ... pourquoi pas :p. Mais j'en ferais pas une régale générale personnellement.

edit : J'ai fini de tout lire, et en effet, comme le dit Joel y'a des trucs assez WTF.
0  0 
Avatar de Joel F
Membre chevronné https://www.developpez.com
Le 05/05/2010 à 22:15
le document tourne depuis pas mal de temps. y a des trucs à dresser les cheveux sur la tete. On en a debatu sur la ML Boost.dev et y a de strucs vraiment laids.

Cependant, dans une boite genre google je comprends ce genre de truc un peu wtf. Apres le suivre comme ça dans un autre cadre, j'y crois moyen.
0  0