¿El peor estándar de codificación que hayas tenido que seguir? [cerrado]

¿Alguna vez ha tenido que trabajar para codificar estándares que:

• ¿Disminuyó enormemente su productividad?
• ¿Se incluyeron originalmente por buenas razones pero se mantuvieron mucho después de que la preocupación original se volviera irrelevante?
• ¿Estuvieron en una lista tan larga que era imposible recordarlos a todos?
• ¿Crees que el autor solo estaba tratando de dejar su huella en lugar de alentar una buena práctica de codificación?
• ¿No tenías idea de por qué estaban incluidos?

Si es así, ¿cuál es su regla menos favorita y por qué?

Algunos ejemplos aqui

Esto puede alterar algunas plumas, pero los estándares que exigen comentarios de bloque con plantilla en la parte superior de cada método siempre me molestan.

1) Siempre están desactualizados ya que están demasiado lejos del código que hace el trabajo real para darse cuenta cuando está actualizando cosas. Los malos comentarios son peores que ningún comentario.

2) A menudo solo repiten información que ya está contenida en la herramienta de control de origen, solo que menos precisa. Por ejemplo: Última modificación por, lista de fecha / razones de modificación.

Tuve una vez un profesor que exigió que tengamos al menos un comentario para cada línea de código.

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

Fue bastante ridículo.

El estándar de codificación de nuestra compañía (C #) exigió el uso extensivo de #REGIONs (para aquellos que no lo saben, marca bloques de código fuente que se colapsarán en una sola línea en Visual Studio). Como consecuencia, siempre abría lo que parecía ser una clase bien estructurada, solo para encontrar montones y montones de basura barridos bajo alfombras profundamente anidadas de construcciones #REGION. Incluso tendría regiones alrededor de líneas individuales, por ejemplo, tener que desplegar una región LOG para encontrar una sola declaración del Logger. Por supuesto, muchos métodos agregados después de que se hizo alguna región, también se colocaron en el ámbito de la región "incorrecta". El horror. El horror.

Las regiones son una de las peores características que se han agregado a Visual Studio; fomenta la estructuración de la superficie en lugar de la estructura real de OO.

Hoy en día, mato #REGIONES a la vista.

En un trabajo nos vimos obligados a usar alguna forma extraña de notación húngara en la base de datos.

No puedo recordar los detalles, pero de memoria, cada nombre de campo tenía que contener:

• Sin vocales
• Todas las letras mayúsculas
• Una referencia a la tabla
• Un indicador de tipo de datos
• Una longitud de datos
• Un indicador anulable

Por ejemplo, la columna que contiene el nombre de una persona podría llamarse: PRSNFRSTNMVC30X(tabla de persona, columna de nombre, Varchar 30 caracteres, no nulo)

Insistiendo en que todas las llaves se sigan con un comentario sobre lo que termina la llave:

p.ej:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

#define AND  &&
#define OR   ||
#define EQ   ==

'Nuff dijo.

• Los nombres de las variables locales están en minúsculas sin guiones bajos

Ejemplos reales: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

El New York Times pesa :

“Los espacios de palabras no deben darse por sentados. El griego antiguo, el primer alfabeto que presenta vocales, podría descifrarse sin espacios de palabras si lo sonara y lo hiciera sin ellos. [...] El latín también dejó de separar las palabras en el siglo II. La pérdida es desconcertante, porque el ojo tiene que trabajar mucho más para leer el texto no separado. Pero, como ha explicado el paleógrafo Paul Saenger, el mundo antiguo no deseaba "hacer que la lectura fuera más fácil y rápida".

Se me pidió por el líder de software de una empresa para hacer " simple, re n código redundante ". Estaba prohibido, por ejemplo, agregar un nuevo parámetro a una función existente. En su lugar, tuvo que duplicar la función, dejando el original intacto para evitar regresiones. Sin pruebas formales, por supuesto (pérdida de tiempo).

También se nos prohibió el uso de software de fusión; cada archivo solo puede ser modificado por un programador a la vez. El software de control de revisiones era ciencia ficción, por supuesto.

El día más feliz de mi vida fue cuando lo despidieron (considere que es muy, muy difícil despedir a alguien en Italia).

Toda interacción con la base de datos debe hacerse a través de procedimientos almacenados . Podría tener sentido si vivimos en 1997 y no en 2010.

Me acabo de dar cuenta de que esto realmente cubre todos los criterios de la pregunta original:

• ¿Disminuyó enormemente su productividad? CHEQUE. Por favor, solo use un ORM .
• ¿Se incluyeron originalmente por buenas razones pero se mantuvieron mucho después de que la preocupación original se volviera irrelevante? CHEQUE. El gerente fue desarrollador de un servidor de bases de datos hace 1000 años y puso este estándar de codificación.
• ¿Estuvieron en una lista tan larga que era imposible recordarlos a todos? CHEQUE. Esto incluía "tanta lógica debería almacenarse en la base de datos como sea posible".
• ¿Crees que el autor solo estaba tratando de dejar su huella en lugar de alentar una buena práctica de codificación? CHEQUE. Sigue volviendo al administrador como un ex desarrollador de servidor de base de datos.
• ¿No tenías idea de por qué estaban incluidos? CHEQUE.

No se le permite usar el STL u otras bibliotecas estándar de C ++ porque el CTO creía que 'nosotros' podríamos hacerlo mejor y más rápido. Incluso construcciones básicas como listas y la clase de cadena.

Notación húngara

Muestra extraída de la " explicación de Charles Simonyi de la convención de nomenclatura de identificadores de notación húngara " en MSDN.

1 #incluye "sy.h"
2 extern int * rgwDic;
3 extern int bsyMac;
4 struct SY * PsySz (char sz [])
6 {
7 char * pch;
8 int cch;
9 struct SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 sin signo wHash = 0;
13 pch = sz;
14 while (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 para (; * pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 char * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 while (* pch == * szSy ++)
24 {
25 if (* pch ++ == 0)
26 retorno (psy);
27}
28}
29 cwSz = 0;
30 if (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 Cero ((int *) psy, cwSY);
34 bltbyte (sz, psy-> sz, cch + 1);
35 retorno (psy);
36}

Una vez trabajé en un proyecto en el que el líder del proyecto exigía que cada variable, CADA variable, tuviera como prefijo "v". Entonces, vCount, vFirstName, vIsWarranty, etc.

¿Por qué? "Porque estamos trabajando en VBScript y todo es una variante de todos modos".

WTF

Casi olvido este:

Cita de un gerente:

No arregle ni documente ningún error que encuentre en su propio código. El cliente nos pagará para identificarlos y corregirlos en los próximos años.

Esto no era para software de consumo, sino personalizado para una sola organización grande. No hace falta decir que el cliente pagó años después. Puede parecer trivial, pero tratar de ignorar los errores es más difícil que encontrarlos.

Comentarios XML forzados sobre todos los métodos no privados, constantes, enumeraciones y propiedades.

Condujo a un código bastante desordenado, especialmente porque el resultado final fue que la gente simplemente presionó /// para crear un código de comentario vacío para todo o instaló GhostDoc y agregó comentarios generados automáticamente:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

[Editar] La razón por la que menciono esto como un estándar ridículo no es porque piense que los comentarios del método son estúpidos, sino porque la calidad de estos comentarios no se hizo cumplir de ninguna manera y resultó en la creación de montones y montones de desorden en los archivos de código . Hay mejores formas de crear documentos de código significativos que el requisito de compilación "debe tener un comentario" ciego.

No es realmente un estándar de codificación, pero teníamos un archivo en el control de origen llamado 'changelog.txt'

Cada vez que realizaba un registro, tenía que agregar manualmente una entrada a este archivo. Esta entrada fue el número de revisión de subversión y su comentario de registro.

Cuando comenzó el nuevo CTO y alguien le dijo esto, tomó una decisión ejecutiva de inmediato y dijo: "Ya no vamos a hacer esto" y eliminó el archivo. Esto había estado sucediendo por años.

Algunos de los lugares con los que he trabajado insistieron en comentar el código no utilizado o en desuso en lugar de eliminarlo. En lugar de confiar en el VCS para el historial, etc., se mantuvo dolorosamente en los archivos a través de un código comentado.

El gran problema que encontré con esto es que a menudo no tenías idea de por qué se comentaba el código. ¿Fue porque algún desarrollador estaba haciendo cambios activamente y quería mantenerlo como referencia o ya no era necesario?

El peor estándar de codificación en el que he participado son las bases de código que no tenían ninguna. Prefiero seguir un estándar de codificación con el que estoy totalmente en desacuerdo que trabajar en bases de código donde no hay ninguno. Hace que sea mucho más difícil aprender nuevas partes de la base del código.

Forzar comentarios en línea para el control de versiones fue sobre el estándar de codificación más inútil que ignoré.

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

El DBA de Oracle que insistió en el uso correcto del espacio en blanco mientras 'mantenía' una base de datos con una tabla altamente contenida que tenía más de 200 campos y 40 disparadores se acerca.

Hice revisiones de código en un proyecto liderado por un primer contador de tiempo de C ++ que decidió que todas las funciones de los miembros de la clase deberían tener como prefijo el nombre de la clase y la visibilidad:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

Estar obligado a sangrar todo el código por cuatro espacios;)

Tuve un trabajo hace años donde todo nuestro código tenía que alinearse a la izquierda, sin sangría. Al chico que se le ocurrió esa política no le gustaba tener que desplazarse horizontalmente cuando miraba largas líneas de código, equiparándolo a jugar ping-pong con los ojos.

Esto es más un ejemplo de cómo no tener los estándares de codificación puede dañar.

Un contratista que trabajaba en un gran banco insistió en que seguir los estándares era el mejor de todos. La aplicación fue escrita en dBase / Clipper, de la cual fue el único desarrollador y, por supuesto, se le ocurrió el estándar.

• Todo está en mayúscula. Me refiero a todo, incluidos los raros comentarios que hizo.
• Sin sangrado.
• El nombre variable fue algo similar a APRGNAME. A = alcance de la variable, por ejemplo, P para público, PRG = primeros tres caracteres del archivo fuente que creó la variable, NOMBRE = nombre de la variable en los 6 caracteres restantes que dBase / Clipper permitió.
• Las primeras 4 y últimas 4 líneas del código fuente tenían 80 * de largo. ¿Por qué? Entonces pudo escuchar la impresora de matriz de puntos comenzando y terminando la impresión de un archivo. La memoria es que todo el programa se imprimió a través del mainframe semanalmente, 20,000 páginas.
• Estoy seguro de que hubo muchos más que me las arreglé para deshacerse de mi cerebro.

Era un programador autodidacta muy nuevo en esa etapa, pero sabía lo suficiente como para no escuchar al científico loco y salir de allí antes de pedir que me hiciera cargo del proyecto.

Y sí, le dijimos a la gerencia lo malas que eran estas prácticas, pero siempre obtuvimos las habituales "le pagaban al contratista el dólar que debía saber de lo que estaba hablando".

Una explosión más de mi pasado.

Cita del dueño de la compañía:

No habrá código escrito usando lenguajes interpretativos porque perdí 25 millones en ese proyecto {improperio} escrito en Java.

El proyecto Java era un sistema de comercio de acciones diseñado para manejar unas pocas docenas de acciones, que ahora se usaba para procesar miles. En lugar de abordar las fallas de diseño o el hardware deficiente, toda la compañía se vio obligada a convertir todas las aplicaciones que no son C / C ++ a C / C ++, y todo el nuevo desarrollo tuvo que ser en C / C ++. Los lenguajes interpretativos significaban cualquier cosa no compilada, y el propietario solo consideraba ensamblador, C y C ++ compilados.

Para una compañía de 800 personas, en la que la mayor parte del código estaba en Java y Perl, esto significaba que toda la compañía pasó la mayor parte de su tiempo durante los próximos dos años reescribiendo código perfectamente perfecto en C / C ++.

Curiosamente, unos veinte años antes de este fiasco, estaba en otra compañía en la que el líder tecnológico decidió que nuestra lógica de clasificación (era un Bubble Sort) necesitaba recodificarse en el ensamblador en lugar de ser reemplazada por Quick Sort porque - Algorithms do No mejora el rendimiento. La única forma de mejorar el rendimiento era reescribir la misma lógica en ensamblador.

En ambos casos, me fui poco después de que cayeran los dictados.

Como muchos programadores (pero no lo suficiente), odio la decoración de código. Me enfurece cuando tengo que usar un prefijo de signo de dólar ($) para nombres de variables o guiones bajos para variables privadas, incluso sin getters / setters. Si necesitas decorar tu código para entenderlo, ¡entonces debes irte!

He estado trabajando con un sistema web durante un tiempo en el que todos los parámetros pasados ​​tenían que llamarse P1, P2, P3, etc. Sin ninguna posibilidad de saber para qué servían sin una extensa documentación.

Además, aunque no es estrictamente un estándar de codificación, en el mismo sistema, cada archivo se llamaría xyz0001.ext, xyz0002.ext, xyz0003.ext, etc., donde xyz era el código de la aplicación en sí mismo.

Esto fue hace mucho tiempo - 1976 para ser exactos. Mi jefe nunca había oído hablar de Edsger Dijkstra ni había leído un número de CACM, pero había escuchado un rumor de que "GOTO es malo", por lo que no se nos permitió usar GOTO en nuestros programas COBOL. Esto fue antes de que COBOL agregara el "final if", por lo que en ese momento solo tenía dos y media de las tres estructuras de control clásicas (secuencia, if / then / else, performance (es decir, do while)). De mala gana permitió GOTO en nuestros programas básicos y las instrucciones de rama en nuestros programas de lenguaje ensamblador.

Lamento que esto sea una especie de historia de "tenías que estar allí". Hasta donde yo sé, cada idioma inventado desde 1976 tiene estructuras de control adecuadas para que nunca necesite usar GOTO. Pero el punto es que el jefe nunca supo POR QUÉ GOTO se consideraba perjudicial, o qué idioma era el trastorno infantil y cuál era la enfermedad mortal.

Trabajé en un proyecto donde el arquitecto jefe exigió escribir (también) código explícito. Uno de los peores ejemplos que encontré en el código (y que felizmente aprobó) fue el siguiente.

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

¡Incluso ReSharper te dijo que esto está mal!

En mi último trabajo, "estándares" sería un término muy fuerte para lo que me dio el tipo que me contrató. Programando sitios web en ColdFusion y SQL, me dieron requisitos de codificación como:

• No use incluye. Me gusta una página grande
• Siempre separe las palabras en nombres de variables y columnas con guiones bajos (excepto isactive, firstname, etc.)
• Nunca use abreviaturas; siempre escriba el nombre (con frecuencia escribía fname, etc.)
• No use nombres confusos (como amount_charged y charge_amount, que midieron cosas diferentes pero relacionadas)
• No use DIV y use CSS mínimo : use tablas anidadas en su lugar (encontré unas seis capas de profundidad, una vez).
• No guarde en caché ninguna consulta. Siempre.
• ¿Vas a usar una variable en más de una página? Alcance de la aplicación.
• Cada página es su propio bloque try / catch. No necesitamos / queremos un controlador de errores global.

Empecé a cambiarlos tan pronto como él renunció.

En mi vida como codificador de C ++, se aplicaron dos "reglas" realmente desagradables:

1. "No podemos usar el STL, porque VC ++ 4.1 no lo admite (y no podemos cambiar a VC ++ 6.0 en este momento)".
2. "No , no utilizar QuickSort, ya que puede ser O (n ^ 2) en los casos malos, el uso de esta implementación del algoritmo HeapSort I (nombre del líder del proyecto suprimido) escribí como estudiante."

Me veo obligado a tener documentación XML para todas las clases y miembros de la clase. Incluido privado. Tengo ganas de usar los comentarios de ghostdoc predeterminados.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}