Odio uno de nuestros estándares de codificación y me vuelve loco, ¿cómo procesarlo? [cerrado]

Descargo de responsabilidad : no es tan exagerado como sugiere el título, pero todavía me incomoda. Solo voy a expresar honestamente, así que tómalo con un grano de sal. Solo imagina que estoy hablando de ese estándar de codificación con el que no te gusta trabajar.

Editar : El hecho de que no me guste no significa que no lo use ni lo imponga.

Decidí hacer esta pregunta con el espíritu de cómo superar un estándar que no le gusta, no para obtener ayuda sobre cómo discutir mejor cómo se puede cambiar (aunque se agradece cualquier comentario sobre esta última parte). Además, trabajo en una gran empresa y es muy poco probable que cambie algo que ha vivido durante tanto tiempo y que importa tan poco.

El estándar es el estándar de apertura-rizado-llave-en-línea dedicada:

somefunction()
{
    //...
}

En lugar del * claramente superior * (tenga en cuenta el tono de broma / frustración):

somefunction() {
    //...
}

Mis argumentos personales contra el estándar:

• Hincha el código : líneas innecesarias adicionales
• Más difícil de escribir : aunque probablemente este sea solo yo luchando con el estándar, sé que una pulsación de tecla adicional no es tan mala.
• No es más fácil de leer : empiezo a leer una declaración de función, una declaración if o cualquier otra declaración de apilamiento de alcance y ya no tengo que buscar una llave de apertura. Los bloques anidados con este estándar solo me enojan por alguna razón.
• Utilizado por personas que provienen de un entorno IDE de Microsoft : creo que debería haber una razón discutida (o más) detrás de un estándar, no solo asimilarlo por paradigma.

Sus argumentos (y mi forma de responderles internamente):

• Más fácil de leer porque puedes ver dónde comienzan y terminan los bloques de inmediato : no puedo entender esto, de qué sirve el bloque si no sabes de qué es propiedad, por lo que debes leer al revés.
• Lo usé en un IDE de Microsoft y me gustó : Uhh ... ¿ok?
• Está en el estándar : * se encoge *

¿Soy el único que lucha con una postura obstinada contra un estándar específico ?, ¿cómo has superado estos? ¿Cuál es tu opinión sobre cuál debería ser este estándar en particular (solo por diversión)?

Si desea superar esto, hubo una cita de Torvalds:

Los malos programadores se preocupan por el código. Los buenos programadores se preocupan por las estructuras de datos y sus relaciones.

Ahora considere, ¿dónde ubica a los programadores que se preocupan por algo tan pequeño como el estilo de refuerzo impuesto por su código estándar? ¿Es su código base de otra manera tan prístino que el refuerzo es el único tema por el que vale la pena discutir?

A algunas personas les gusta a tu manera y a otras no. De cualquier manera, alguien va a estar molesto. Es solo tu turno esta vez. Respira y continúa con el trabajo.

¿Está documentado el estándar del equipo? Si es así, ¿hay alguna razón en la guía de estilo? Honestamente, he tenido que aguantar un montón de veces y hacer un trabajo real. Hay problemas peores que tener, pero te siento, todavía está molesto (por cierto, estoy de acuerdo contigo en el estilo).

Lo que me ayudó a superarlo:

1. Se dio cuenta de que hay beneficios reales para un estilo único (sin importar cuál sea). O al menos un grupo de personas piensa que sí .
2. Exactamente lo que acaba de hacer, escriba por qué se siente mal, para que pueda plantear bien el argumento en el futuro.
3. Usa una herramienta de estilo por el amor de Dios , te salvará la cordura. ReSharper , CodeMaid , StyleCop , JSLint , CheckStyle , etc ... incluso Visual Studio lo hará por usted .
4. Dale un puntapié a este proyecto y prepárate para el próximo cuando puedas establecer los estándares.

La superioridad de una convención sobre la otra es * claramente arbitraria * .

Los problemas de legibilidad que enfrenta, o los compañeros de su equipo enfrentarían con su estándar, son solo una resistencia psicológica al cambio.

El argumento objetivo de legibilidad está a favor de * consistencia * en toda la base del código.

Piense en un momento en que estaba seguro de que tenía razón sobre algo y, durante un período de tiempo, se dio cuenta de que estaba equivocado, o al menos de que estaba exagerando todos esos años atrás. Considere la posibilidad de que pueda estar equivocado nuevamente, y dé tiempo al nuevo estándar de codificación o proceso para convencerlo.

Mis propios estándares de furia cuando era bastante nuevo en la codificación (digamos cinco años en mi carrera) era si los identificadores de varias palabras deberían ser WrittenLikeThiso no written_like_this. Ni siquiera diré cuál me gustó, pero el punto es que después de algún tiempo cambié de bando y después de un tiempo más no me importó de ninguna manera.

La diferencia estándar que está describiendo con las llaves es en gran medida arbitraria. Ambas formas son igualmente buenas y para una empresa, siempre y cuando todos lo hagan igual, todo está bien.

El "claramente superior" del que estás hablando es el tipo de superior del que las personas hablan cuando hablan de cosas "a las que están acostumbrados".

Te acostumbrarás pronto y en un año más o menos, la otra forma será "claramente superior".

En resumen: lidiar con eso.

Este tema particular equivale a una Guerra Religiosa entre aquellos que prefieren un estilo sobre el otro. Muy pocas personas son ambivalentes ...

Finalmente, ninguno de los dos está bien y ninguno está mal.

Las guías de estilo y los estándares de codificación existen por varias razones, y un aspecto clave es garantizar la uniformidad del diseño, que tiene como objetivo reducir la cantidad de errores obvios y mejorar la capacidad de mantenimiento.

¿Soy el único que lucha con una postura obstinada contra un estándar específico?

La respuesta corta es "No", no eres el único. Pero hay cosas más importantes de las que preocuparse. Incluso en los estándares a los que uno ha contribuido, siempre habrá un compromiso: sea testigo de algunos de los aspectos que lo han convertido en C99 y C12 que no tienen sentido para mí.

Incluso MISRA-C (sobre el que tengo influencia directa) contiene elementos con los que personalmente no estoy de acuerdo, pero puedo entender por qué los demás sienten la justificación.

¿Cómo has superado esto?

Y ahí está la respuesta: en lugar de centrarse en por qué no le gusta personalmente, intente comprender por qué la persona / personas que acordaron lo hicieron.

Por lo general, se introducen reglas (en una puerta estable que se cierra después de que el caballo se haya echado a un lado) para abordar un problema anterior. Y si la regla aún no tiene sentido, hable con el propietario estándar e intente "educarlos".

Creo que solo necesitas seguir adelante. Intentaré abordar sus notas con mis propias opiniones:

• Código de hinchazón

  Una línea de código adicional no es un código de relleno, a menos que esté escribiendo cientos de métodos en una sola clase, que agregará cientos de líneas adicionales. Por otra parte, si tiene cientos de métodos en una sola clase, tiene otro problema por completo.

• Más difícil de escribir

  No puedo estar más en desacuerdo con usted sobre esto, de todos modos tiene que presionar la tecla de retorno para pasar a la siguiente línea. ¿Qué hay de que es más difícil de escribir?

• Mas dificil de leer

  Siento que cada línea en un fragmento de código debe tener una función específica. Después de esto, necesitaría definir el nombre del método en una línea, luego las llaves de apertura y cierre en sus propias líneas separadas.

• Usado por personas que provienen de un fondo MS IDE

  Uhh ... ok?

En resumen, parece que usted está siendo insensato acerca de ser un desarrollador .Net en comparación con cualquier otro tipo de desarrollador como si fuera inferior porque usaron un IDE que por defecto es este estándar.

¿Soy el único que lucha con una postura obstinada contra un estándar específico?

Por supuesto no. ¡Las reuniones para determinar los estándares de codificación son horribles! Se prolongan durante horas y los participantes se involucran personalmente en conseguir su propia idiosincrasia favorita (e invariablemente incorrecta, excepto la mía) consagrada en el estándar. Al final, nadie está contento con el resultado. Si algo puede ser peor que la reunión de estándares de codificación, son las reuniones formales de revisión de códigos en los varios meses que siguen a la determinación del estándar: algunas personas intentan adoptar el estándar, mientras que otras (intencionalmente o no) lo ignoran, y usted obtiene horas de comentarios como: en las líneas 132, 142, 145, 181, 195 y 221 de SillyFileConverter.cpp, coloca la llave de apertura en la misma línea cuando el estándar de codificación dice claramente que debería estar en la línea siguiente .

¿Cómo has superado esto?

A su manera, las reuniones ayudan. Incluso si simpatiza por completo con el tipo que dejó la llave de apertura en la misma línea que el condicional, o lo que sea, sin embargo, se enojará con él por perder su tiempo no solo absorbiéndolo y siguiendo el estúpido estándar. Si el tipo es un cascarrabias y hace lo mismo una y otra vez, se vuelve aún más molesto. Estar molesto por ese comportamiento hace que sea mucho más fácil justificar la escritura en un estilo un poco diferente de lo que preferirías , después de todo, ciertamente no quieres ser ese tipo .

Incluso si no está sujeto a revisiones formales interminables del código, puede intentar revisar su propio código específicamente para cumplir con el estándar. No importa lo que piense del estándar, solo está comparando lo que ha escrito con lo que dice el estándar. Si se cansa cada vez que no cumple, eso puede proporcionar algunos de los comentarios negativos que necesita para ayudarlo a adoptar el estándar.

Con este tipo de cosas recuerdo a Gulliver en Liliput. Los liliputienses habían estado librando una guerra sobre el final para abrir un huevo hervido. (La gran lucha endian, little endian original).

Tómelo como una oportunidad para reírse de sí mismo, realmente no vienen con suficiente frecuencia en los negocios.

Su ejemplo particular es desafortunado, ya que algunos estarán de acuerdo y otros no. No estoy de acuerdo con sus argumentos en contra, por ejemplo, y estoy seguro de que muchos otros lo estarán, así como estoy seguro de que muchos otros estarán de acuerdo con ellos. Casi me hace pensar que la pregunta debería cerrarse, ya que es muy subjetiva.

Sin embargo, la pregunta sobre cómo lidiar con un estándar con el que no está de acuerdo es más posible de responder. Creo que la respuesta es que cuando existen pautas de estilo y se acuerdan y se han utilizado, la respuesta es simplemente sonreír, soportarlo y simplemente lidiar con eso. Considere que tener consistencia es más importante. Si la directriz es inexacta o incorrecta, puede haber un argumento para el cambio, pero esto es estilístico, por lo que no hay argumento realmente aparte de la preferencia personal.

Originalmente provenía de un fondo Java, así que seguí el estándar que mencionaste. Luego me mudé a más C ++ y C # donde se usa el estilo que odias. Pero no tiene una respuesta correcta o incorrecta. Lo más importante es tener un estándar seguido por todos. Si un estándar de codificación es estilístico como este y no está claramente equivocado, entonces tratar de argumentar que solo causará fricción en el equipo.

Un formateador + check in hook es un buen comienzo. Pero no es suficiente, ya que lo que escribe no es tan importante como lo que mira todo el día. En algunas situaciones, el enfoque del modo Gafas de Emacs (mantener los archivos en su estilo pero mostrarlos más cerca de su estilo) es atractivo.

Mi experiencia con él, enfrentando exactamente el problema para el que fue escrito, CamelCapsvs underscore_separated, fue que rápidamente se volvió más molesto que útil, pero durante un par de semanas suavizó mi transición para aceptar (a regañadientes) el estilo de la compañía, y también me proporcionó una salida para canalizar mi ira ("ah, lo odio, déjame ajustar la configuración de nuevo ... allí, al menos hice algo ") ;-)

De todos modos, el modo Gafas no maneja la colocación de llaves, es probable que no use Emacs y no lea el código exclusivamente en su editor :-(
Pero el último punto también es una oportunidad, si lee el código la mayor parte del tiempo en una herramienta separada, puede hackear eso para convertir estilos sin preocuparse por el ruido de reformateo de ida y vuelta, ¡porque es de solo lectura! Específicamente, si lee el código en algunas interfaces web, use Greasemonkey.

Aquí hay algunas ideas más fáciles para la mitigación leve:

• Elija una fuente más ancha pero no tan alta para recuperar las líneas de pantalla perdidas.

  • Use la pantalla completa con más frecuencia, si está disponible.

• Configure llaves para resaltarlas en un color sutil (¿y una fuente más pequeña?), Haciéndolas menos visibles que el resto del código. La sangría debería ser suficiente para leer, esp. con el espacio vacío de las {líneas ...

• Asegúrese de que su editor resalte la llave de apertura correspondiente cuando haya terminado }; podría ayudar un poco cuando sus ojos instintivamente vayan al lugar equivocado.

• Re "más difícil de escribir": obtenga un editor real, configúrelo para abrir una nueva línea automáticamente cuando presiona {.

Vive con ello.

Esto es claramente cosmético y no cambia nada sobre la calidad del código o su productividad como desarrollador. Nada por lo que valga la pena comenzar una discusión.

Para ese tipo de estándar de codificación, elegiría la consistencia en la base del código y la legibilidad sobre cualquier enfoque "religioso" particular (incluso bien razonado) cualquier día.

Pensarlo como una decisión democrática de la mayoría de los miembros del equipo sobre un problema no tan importante puede ayudarlo a superarlo.

Es el estándar:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

La mayoría de los que dicen "es el estándar" están siguiendo el principio de "cinco monos".

Simplemente adelante y use el estilo que desee. Luego, use un poco de embellecedor de código para cambiar el código en formato estándar, o corrija su propia aplicación pequeña que convertirá el código de su estilo al estilo estándar dado. Use el embellecedor antes de registrar el código.
También puede hacer lo contrario para cambiar el código registrado del formato estándar a su formato, cuando esté trabajando en él.