Tomaré la opinión controvertida y diré no, no necesitas un estándar de codificación . O bien las reglas son, como usted dice, las pautas aplicables de IDE, las mejores prácticas generales que todos en cada compañía deben seguir, o son llamadas de juicio caso por caso por equipo que debe ser realizada por más de una persona en un equipo capacitado. A través de la programación de pares o revisiones de código.
Cosas como ¿Cómo deberíamos nombrar esta variable? ¿Qué características del lenguaje debemos usar? ¿Debemos evitar? ¿Qué prueba es mejor? Es mejor dejarlos sin respuesta hasta que encontremos el problema estrechamente definido en el que estamos trabajando en este momento .
Cristalizadas a partir de estas decisiones minuciosas, pueden surgir estándares / patrones informales dentro de los equipos, en función de la intersección con el dominio del problema actual y las tecnologías en uso. Al codificar estos medios, creemos que cosas como el estándar de nomenclatura, el subconjunto de lenguaje apropiado, etc., utilizados en estos proyectos, basados en cientos de micro decisiones, y adoptados de manera informal por estos equipos deberían guiar cada proyecto en el futuro.
En principio, suena como una gran cosa, pero en realidad solo se convierte en un imán para la política. ¿Qué herramientas podemos obligar a todos a usar? ¿Qué quiero forzar a otras personas a evitar? Si todos estuvieran de acuerdo con estas preguntas, no necesitaríamos un estándar. Simplemente lo haríamos. En mi experiencia, los estándares surgen del deseo de que un subconjunto de desarrolladores ejerza el control sobre otro subconjunto. Por lo general, este tipo de política y la vigilancia tecnológica que lo sigue solo frena la innovación en lugar de proporcionar orientación.
Si desea orientación real , en lugar de leer un estándar con un montón de reglas inútiles, vaya a buscar miembros capaces de su equipo y pregúnteles qué piensan. ¿Qué han sido quemados por? ¿Cómo te sugieren que escribas código? Obtendrá una variedad de respuestas útiles con mucha experiencia valiosa para respaldarlo. Verás muchas intersecciones basadas en experiencias comunes. En lugar del monocultivo impuesto por el estándar, también verá mucha diversidad que solo puede ayudarlo a ver muchas formas válidas de resolver problemas.
Y cuando alguien le dice que no haga algo debido a una regla en el "estándar" pero no tiene experiencia o respaldo razonable para su reclamo, ignórelo. Aquí el estándar no ha servido a nadie ni ha hecho a nadie un mejor desarrollador.