The last time of your life.

Les règles de codage sont un ensemble de règles à suivre pour uniformiser les pratiques de développement logiciel, diffuser les bonnes pratiques de développement et éviter les erreurs de développement "classiques" au sein d'un groupe de développeurs.
Les règles de codage s'articulent autour de plusieurs thèmes, les plus courants étant:
Le nommage et l'organisation des fichiers du code source
le style d'indentation
Les conventions de nommage, ou règles de nommage
Les commentaires et documentation du code source
Recommandations sur la déclarations des variables
Recommandations sur l'écriture des instructions, des structures de contrôle et l'usage des parenthèses dans les expressions.

Les règles de codage permettent d'assurer une meilleure lisibilité du code en utilisant le même style de codage et en évitant les constructions qui rendent le code difficile à lire ou à modifier. Elle permettent également d'éviter les erreurs liées au langage pouvant donner des résultats incorrects, pouvant entraîner des crashs systèmes ou des failles de sécurité. Certaines règles sont également liées aux buts poursuivis par le projet logiciel: portabilité, contraintes mémoires, criticité, etc.
Les règles de codage participent à la qualité logicielle. Ainsi, plus l'importance des développement est élevée, plus les besoins en règles de codages est nécessaire. Ainsi, les normes DO-178B pour l'avionique et MISRA C pour l'automobile imposent un ensemble d'objectifs à atteindre sur le logiciel selon la criticité qui lui est attribuée. Cette criticité est déterminée par les contraintes soumises au logiciel (mémoire et CPU disponible, fiabilité, robustesse, etc.) et les risques liés à l'utilisation de ce logiciel (risques humains, risques financiers, etc.). Les règles de codage sont adaptées en conséquence. Par exemple, un logiciel embarqué disposant de peu de mémoire ne devra pas utiliser l'allocation dynamique de mémoire. Autre exemple: le logiciel redondant d'une fusée doit être développé par une équipe totalement indépendante et séparée (pas de partage de code, pas de partage de la conception, etc.) de l'équipe développant le logiciel redondé, le développement devant se faire avec les mêmes contraintes pour les deux équipes.
Il n'y a pas de règle de programmation absolue, et il appartient à chaque projet logiciel de définir celles qui lui correspondent le mieux.
Tout manquement à une règle de programmation est appelée une violation de règle.