Standards de programmation

Dans la pratique de la programmation, la question des standards de programmation est matière à débats : indenter avec des espaces ou des tabulations? Comment marquer l'indentation? Comment nommer les variables, les types et les fonctions? Y a-t-il des mots clés à éviter ou des façons de faire qui sont proscrites dans une entreprise ou dans un projet donné? Et ainsi de suite. Par exemple, certains domaines d'application sont réfractaires aux exceptions, d'autres à la récursivité, d'autres encore éviteront la programmation générique ou les conteneurs standards, etc.

Les standards de programmation entraînent une sorte signature pour le code, et donnent une impression d'homoigénéité stylistique pour un groupe donné. Ce faisant, ils facilitent la compréhension du code aux gens du même groupe qui le rencontrent pour la première fois : les indices visuels et les façons de faire communes accélèrent le repérage des éléments clés d'un programme et permettent aux gens de se concentrer sur l'essentiel.

Quelques standards de programmation au sens large

Les standards qui suivent sont des exemples de diverses provenances. Aucun n'a raison dans l'absolu.

Pour C :

• Le standard appliqué dans le noyau de Linux : https://www.kernel.org/doc/html/latest/process/coding-style.html (c'est amusant en plus!)
• Une proposition de Malcolm Inglis : https://github.com/mcinglis/c-style
• Le standard de Rob Pike : http://www.lysator.liu.se/c/pikestyle.html
• Chez CERT : https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Coding+Standard

Pour C# :

Proposition de règles pour programmer avec C# dans Unity (je ne sais pas s'il s'agit d'un standard accepté par la communauté) : http://wiki.unity3d.com/index.php/Csharp_Coding_Guidelines

Pour C++ :

• Chez Google : http://google-styleguide.googlecode.com/svn/trunk/cppguide.html
  • pour une justification de ces règles, voir cette présentation de Titus Winters à CppCon 2014 : https://www.youtube.com/watch?v=NOCElcMcFik
  • pour une critique détaillée de ces règles, voir ce texte de Robert C. Martin en 2014 : http://www.randomprogramming.com/2014/10/googles-c-style-guide/ (puis http://www.randomprogramming.com/2014/10/googles-c-style-guide-follow-up/ pour un commentaire plus détaillé, en lien avec la présentation de Titus Winters)
  • plus spécifiquement, dans le projet Chromium : http://chromium-cpp.appspot.com/
  • critique sévère du guide de Google pour C++, par Sergey Zubov en 2014 : https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker
  http://www.possibility.com/Cpp/CppCodingStandard.html
• http://www.doc.ic.ac.uk/lab/cplus/c++.rules/
• http://www.chris-lott.org/resources/cstyle/CppCodingStandard.html
• http://www.stevenpigeon.org/Essais/std_prog/std_prog.html
• Chez GNU : http://gcc.gnu.org/wiki/CppConventions
• Chez Mozilla : https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
• Chez CERN, pour le projet ATLAS : http://atlas-computing.web.cern.ch/atlas-computing/projects/qa/draft_guidelines.html
• Le « standard PPP », proposé en 2011 par Bjarne Stroustrup et qui se veut pragmatique (mais est, en pratique, son style personnel). Il y a de bonnes idées là-dedans, cela dit, dont « faire de la longueur d'un nom un reflet de sa portée » (donc : un nom long si la variable vit longtemps, un nom court si sa vie est limitée; un compteur nommé i est Ok, mais une variable globale nommée x ne l'est pas) : http://www.stroustrup.com/Programming/PPP-style.pdf
• Chez LLVM : http://llvm.org/docs/CodingStandards.html
• Chez Insomniac Games : https://gist.github.com/Kerollmops/fcad27cfef9e3552cb75a3d201494ba6
• Chez Epic Games, pour le moteur Unreal : https://dev.epicgames.com/documentation/en-us/unreal-engine/epic-cplusplus-coding-standard-for-unreal-engine?application_version=5.4
• Chez WG21, dans le groupe LEWG, un guide pour soumettre des propositions dont la terminologie est de qualité est disponible sur : https://github.com/cplusplus/LEWG/blob/master/library-design-guidelines.md
• Réflexion d'Arne Mertz en 2018 sur la question des styles de programmation en C++ : https://arne-mertz.de/2018/05/trailing-return-types-east-const-and-code-style-consistency/

Pour Go :

• http://talks.golang.org/2013/bestpractices.slide#1

Pour Java :

• http://mindprod.com/jgloss/codingconventions.html
• http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html (qui se concentre sur l'indentation)
• http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_Java.pdf
• le guide de style de Google pour Java : http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

Pour JavaScript :

• Ce n'est vraiment pas simple de trouver une manière convenable d'organiser le code dans ce langage : https://gist.github.com/357981
• Le guide de style de Google : http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
  • quelques leçons à en tirer, de l'avis de Daniel Simmons en 2018 : https://medium.freecodecamp.org/google-publishes-a-javascript-style-guide-here-are-some-key-lessons-1810b8ad050b

Pour Lisp :

• Le guide de style de Google pour Lisp : https://google-styleguide.googlecode.com/svn/trunk/lispguide.xml

Pour les langages de la plateforme .NET :

• http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Pour Objective-C :

• Le guide de style du New York Times : https://github.com/NYTimes/objective-c-style-guide

Pour Python :

• Le guide de style de Google : http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
• Le code Python idiomatique, par Jeff Knupp en 2012 : http://www.jeffknupp.com/blog/2012/10/04/writing-idiomatic-python/
• Le guide PEP, canon de la pratique en Python : http://www.python.org/dev/peps/pep-0008/
  • un complément au PEP, proposé par Goran Milovanovic en 2013 : http://www.nilunder.com/blog/2013/08/03/pythonic-sensibilities/

Pour Ruby :

• https://github.com/styleguide/ruby

Pour Scala :

• http://docs.scala-lang.org/style/method-invocation.html

Pour les shells :

• le guide de style de Google : http://google-styleguide.googlecode.com/svn/trunk/shell.xml

Chez X.org :

• http://www.x.org/wiki/CodingStyle (ce n'est pas nécessairement mon choix de standard, mais j'aime qu'il soit simple et concis)

Pour le Web :

• Les standards côtés client promulgués par l'entreprise isobar : http://na.isobar.com/standards/
• Sans qu'on ne parle vraiment de programmation ici, Google offre son guide de style pour HTML et CSS : http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml

Pour les projets GNU :

• http://en.wikipedia.org/wiki/GNU_coding_standards
• http://www.gnu.org/prep/standards/

Autres :

• Liste de standards de programmation : http://repeatgeek.com/technical/a-list-of-coding-standard-websites/
• Guides de styles de Google : https://code.google.com/p/google-styleguide/
• Quelques standards sur lesquels les programmeurs s'accordent, selon Phil Johnson en 2014 : http://www.infoworld.com/slideshow/141285/coding-conventions-9-areas-where-developers-actually-agree-236851
• Le standard du département d'informatique de l'Université de Sherbrooke : http://pages.usherbrooke.ca/bfraikin/Departement/normes-de-programmation.pdf
• Standards programmatiques appliqués au Collège Lionel-Groulx :
  • dans le cours 420-201-RE : ../../CLG/Cours/420201/index.html
  • dans le cours 420-202-RE : ../../CLG/Cours/420202/index.html
• Une réflexion sur les guerres qui naissent des prises de position quasi-religieuses quant aux guides de style en programmation, proposée par Bill Sourour en 2017 : https://medium.freecodecamp.com/the-100-correct-coding-style-guide-5b594a1655f0
• Réflexion de 2017 par Jay Thomas sur la nécessite des standards de programmation dans un contexte contemporain : http://mil-embedded.com/guest-blogs/coding-standards-are-they-necessary/
• Étude d'Aylin Caliskan, Fabian Yamaguchi, Edwin Dauber, Richard Harang, Konrad Rieck, Rachel Greenstadt et Arvind Narayana en 2018, qui montre que le style de programmation des individus survit (en partie) à la compilation, jusque dans le code généré : https://arxiv.org/pdf/1512.08546.pdf
• Réflexion d'Arthur O'Dwyer en 2023 sur le rôle des Style Guides, à savoir ce qu'ils devraient faire et ce qui n'est pas de leur ressort : https://quuxplusone.github.io/blog/2023/08/11/style-guide-guide/

Critiques :

• En 2012, Richard Rodger explique pourquoi il a tout simplement abandonné l'idée d'appliquer un standard de programmation (outre les pratiques individuelles) : http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/
• Dans ce texte de 2016, Rockford Lhotka relate son expérience avec des standards de programmation qui lui semblent ridicules... et montre pourquoi l'alternative, soit ne pas avoir de standard de programmation commun, est... nettement pire : http://www.lhotka.net/weblog/CodingStandardsHorrorStory.aspx