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 |
Bonjour,
Envoyé par Luc Hermitte
les tabulations c'est pour indenter (début de lignes - à gauche), et les espaces pour "l'ascii art" (en fin de lignes - à droite)
