Règles de codage, mes amours

Il n'est pas rare d'avoir quelques règles de codage dictées lors du développement d'un programme dans une entreprise, ou dans un projet en général. En soi, c'est plutôt bien, ça rend souvent le code plus homogène, lisible ou maintenable. Certaines règles se justifient pour les besoins de performances, de documentation ou de fiabilité. Mais parfois...

• Pas de ligne de plus de 131 caractères. Moral, mais pourquoi pas 132 ou 130 ?
• Minimiser les boucles, mais maximiser leur portée. Hein ?
• Pas d'identifieur (nom de classe, variable ou package) de plus de 31 caractères. Si ça parait évident, attendez de voir la suivante... (et celle d'après !)
  
• Les noms des identifieurs doivent être clairs et représenter l'objet identifié. Par exemple, "Initialize_Space_Craft_With_One_Pilot" et non pas "Init_SC_with1_pilot". Hahahaha !!!
• Interdiction d'utiliser use. RHAHahahaha... BANG!
• Pas d'appel récursif. Boom.
• Pas de condition IF sans ELSE. Peut se justifier par des raisons de fiabilité (le codeur a effectivement envisagé le cas contraire et écrit exlicitement null, avec commentaires dans le ELSE).
• Dans les CASE-WHEN, interdiction d'utiliser when others. Moral pour la fiabilité (Ada95 plante si l'on omet un cas possible), parfois très pénible en pratique (heureusement que l'Ada admet les OR dans les CASE, parce qu'avec des litéraux de 15 à 20 entrées...).
• Les variables doivent être déclarées dans l'ordre d'apparition dans le code. Dumbest rule ever.
  

J'en passe et des meilleures. L'important est surtout de mettre au point ces normes avant de commencer l'implémentation... Dommage pour certains, pas vrai ?

Mais quelles sont les règles de codage indispensables en réalité ? Celles qui apportent effectivement la lisibilité, la fiabilité et la maintenabilité ?