Pour autant que je sache, la déclaration qui vous a troublé est un compromis pragmatique fait pour que les lignes directrices puissent servir un public aussi large que possible. En fonction de votre contexte spécifique (plus d'informations ci-dessous), vous pouvez avoir une option pour l'ajuster et utiliser plus efficacement les directives.
Vous voyez, les lignes directrices font référence à de «fortes objections personnelles» comme moyen de justifier la violation. De telles objections ne sont pas quelque chose à ignorer à la légère, surtout si elles proviennent de développeurs expérimentés.
Ces objections peuvent être erronées, faites attention, mais (et c'est très GRAND MAIS), elles peuvent également indiquer qu'une règle particulière est erronée - généralement ou dans le contexte du projet spécifique (un exemple de déréglementation de règle est une obligation de fournir journalisation détaillée dans le code critique de performance).
Je pense que tout guide de style sensé devrait prendre en compte ce qui précède et essayer de répondre à un éventuel besoin de s'ajuster. Maintenant, si le guide qui vous a dérouté ne visait que des équipes matures avec des processus et un environnement efficaces et fluides, il pourrait être énoncé de manière beaucoup moins ambiguë, par exemple comme ceci:
Les règles doivent être suivies strictement, à moins qu'une contestation ne soit lancée contre elles - auquel cas la règle contestée doit rester ignorée jusqu'à ce qu'elle soit résolue - soit en rejetant la contestation, soit en l'acceptant et en ajustant les règles en fonction.
Vous aimerez peut-être mieux ce qui précède et vous voudrez peut-être qu'il en soit ainsi partout, pour tout le monde, mais examinez de plus près cette partie «le défi est relevé / restez ignoré / ajustez» et demandez-vous comment il peut être mis en œuvre. Demandez-vous combien de temps cela peut prendre en fonction du projet et de l'équipe. Si cela prend une heure, est-ce acceptable? Et si cela prend un jour, une semaine ou ... un mois?
Vous voyez, cette approche défi-et-ignorer-jusqu'à-résolu pourrait ouvrir une large porte aux abus si elle était présentée comme un guide pour tout projet. "Ouais ouais nous vous entendons, faisons-le comme le guide le dit. Tout d'abord, remplissez ce formulaire de défi et obtenez les approbations du PDG / CFO / CTO. ; cela peut prendre une semaine ou deux. En attendant, assurez-vous que votre code critique de performances vomit des instructions de journalisation correctement formatées à chaque déplacement de registre. "
Je ne peux pas lire dans l'esprit des auteurs du guide, mais il semble raisonnable de supposer qu'ils voulaient éviter de l'utiliser pour justifier un gâchis comme décrit ci-dessus. De ce point de vue, il est tout simplement plus sûr d'affirmer clairement que le guide ne suppose aucune application - de cette façon, même maladroite, il permet toujours d'être utilisable pour un large éventail arbitraire d'équipes et de projets. On s'attend probablement à ce qu'une allocation aussi large laisse aux équipes plus matures et efficaces la possibilité de la réduire raisonnablement sans nuire à la productivité des développeurs.
Appliqué à votre cas spécifique, écrivant le document de style de codage pour votre équipe et échouant à la révision du code si le style ne correspond pas - je pense que vous devez comprendre combien de temps il faut aux développeurs pour contester une règle particulière, la faire ignorer, résolu, et faites-le changer ou récupérer selon la résolution.
Si vous trouvez un moyen de faire fonctionner ce processus sans introduire de nombreux obstacles dans votre flux de travail de développement, alors une approche formelle et facile à suivre de défi / résolution vaut vraiment la peine d'être envisagée au lieu du chaotique "violer si vous pleurez assez fort".
En guise de remarque, je voudrais aborder ce que vous avez écrit dans un autre commentaire , "Supposons que le style de codage est idéal, et si ce n'est pas le cas, etc."
C'est vraiment une hypothèse dangereuse. Je me suis cassé le nez dessus (deux fois! En un seul projet! Où j'avais une vaste expérience et imaginé que je sais tout à ce sujet, allez comprendre) et je vous recommande fortement de le laisser tomber. Il est plus sûr de supposer que le guide de style peut contenir des erreurs et de réfléchir à ce qu'il faut faire si de telles erreurs sont découvertes.