¿Cuál fue la regla estándar de codificación más extraña que se vio obligado a seguir? [cerrado]

Cuando hice esta pregunta , casi siempre recibí un sí definitivo, debería tener estándares de codificación.

¿Cuál fue la regla estándar de codificación más extraña que alguna vez se vio obligado a seguir?

Y por extraño quiero decir más gracioso, o peor, o simplemente extraño.

En cada respuesta, mencione el idioma, el tamaño de su equipo y los efectos nocivos que le causaron a usted y a su equipo.

Me odio cuando se prohibió el uso de múltiples retornos.

sangría inversa. Por ejemplo:

    for(int i = 0; i < 10; i++)
        {
myFunc();
        }

y:

    if(something)
        {
// do A
        }
    else
        {
// do B
    }

Tal vez no sea el más extravagante que obtendrás, pero realmente odio cuando tengo que hacer un prefacio de los nombres de las tablas de la base de datos con 'tbl'

Casi cualquier tipo de notación húngara.

El problema con la notación húngara es que a menudo se malinterpreta. La idea original era prefijar la variable para que el significado fuera claro. Por ejemplo:

int appCount = 0; // Number of apples.
int pearCount = 0; // Number of pears.

Pero la mayoría de la gente lo usa para determinar el tipo.

int iAppleCount = 0; // Number of apples.
int iPearCount = 0;  // Number of pears.

Esto es confuso, porque aunque ambos números son enteros, todos lo saben, no se pueden comparar manzanas con peras.

No se permite ningún operador ternario donde trabajo actualmente:

int value = (a < b) ? a : b;

... porque no todos "lo entienden". Si me dijera: "No lo use porque hemos tenido que reescribirlos cuando las estructuras se vuelven demasiado complicadas" (¿operadores ternarios anidados, alguien?), Entonces lo entendería. Pero cuando me dices que algunos desarrolladores no los entienden ... um ... Claro.

NUNCA elimine ningún código al hacer cambios. Nos dijeron que comentaramos todos los cambios. Tenga en cuenta que usamos el control de fuente. Esta política no duró mucho porque los desarrolladores estaban alborotados al respecto y cómo haría que el código fuera ilegible.

Una vez trabajé bajo la tiranía de Mighty VB King .

El VB King era el maestro puro de MS Excel y VBA, así como de las bases de datos (de ahí su apellido: jugó con Excel mientras los desarrolladores trabajaban con compiladores, y desafiarlo en las bases de datos podría tener efectos perjudiciales en su carrera ... ).

Por supuesto, sus inmensas habilidades le dieron una visión única de los problemas de desarrollo y las soluciones de gestión de proyectos: aunque no codificó exactamente los estándares en el sentido más estricto, el Rey VB regularmente tenía nuevas ideas sobre los "estándares de codificación" y las "mejores prácticas" que intentó (y muchas veces tuvo éxito) para imponernos. Por ejemplo:

• Todas las matrices C / C ++ comenzarán en el índice 1, en lugar de 0. De hecho, el uso de 0 como primer índice de una matriz es obsoleto y ha sido reemplazado por la perspicaz gestión del índice de matriz de Visual Basic 6.

• Todas las funciones devolverán un código de error: no hay excepciones en VB6, entonces, ¿por qué las necesitaríamos? ( es decir, en C ++ )

• Dado que "Todas las funciones devolverán un código de error" no es práctico para las funciones que devuelven tipos significativos, todas las funciones tendrán un código de error como primer parámetro [entrada / salida].

• Todo nuestro código verificará los códigos de error ( esto condujo al peor de los casos de sangría de VBScript que vi en mi carrera ... Por supuesto, como las cláusulas "else" nunca se manejaron, en realidad no se encontró ningún error hasta demasiado tarde )

• Como estamos trabajando con C ++ / COM, comenzando este mismo día, codificaremos todas nuestras funciones de utilidad DOM en Visual Basic.

• Los errores de ASP 115 son malos. Por esta razón, usaremos On Error Resume Next en nuestro código VBScript / ASP para evitarlos.

• XSL-T es un lenguaje orientado a objetos. Usa la herencia para resolver tus problemas (la sorpresa tonta casi me rompe la mandíbula este día ).

• No se utilizan excepciones, por lo que deben eliminarse. Por esta razón, desmarcaremos la casilla de verificación que solicita la llamada del destructor en caso de que se desenrolle la excepción ( a un experto le tomó días encontrar la causa de todas esas pérdidas de memoria, y casi se volvió loco cuando descubrió que habían ignorado voluntariamente (y oculto) su nota técnica sobre la comprobación de la opción de nuevo, enviado un puñado de semanas antes ).

• detecte todas las excepciones en la interfaz COM de nuestros módulos COM y deséchelas en silencio (de esta manera, en lugar de fallar, un módulo solo parecería ser más rápido ... ¡Brillante! ... Como usamos el manejo de errores über descrito anteriormente, incluso nos llevó algún tiempo para entender lo que realmente estaba pasando ... no se puede tener tanto la velocidad y resultados correctos, ¿verdad? ).

• A partir de hoy, nuestra base de código se dividirá en cuatro ramas. Gestionaremos su sincronización e integraremos todas las correcciones / evoluciones de errores a mano.

Todos los arreglos excepto C / C ++ , las funciones de la utilidad VB DOM y XSL-T como lenguaje OOP se implementaron a pesar de nuestras protestas. Por supuesto, con el tiempo, algunos fueron descubiertos, ejem , rotos y abandonados por completo.

Por supuesto, la credibilidad de VB King nunca sufrió por eso: entre la alta gerencia, él seguía siendo un experto técnico "top gun" ...

Esto produjo algunos efectos secundarios divertidos, como puede ver siguiendo el enlace ¿Cuál es el mejor comentario en el código fuente que haya encontrado?

En los años 80/90, trabajé para una compañía de simuladores de aviones que usaba FORTRAN. Nuestro compilador FORTRAN tenía un límite de 8 caracteres para nombres de variables. Los estándares de codificación de la compañía reservaron los tres primeros para la información de estilo de notación húngara. ¡Así que tuvimos que intentar crear nombres de variables significativos con solo 5 caracteres!

Trabajé en un lugar que tenía una fusión entre 2 compañías. El 'dominante' tenía un servidor principal escrito en K&R C (es decir, antes de ANSI). Obligaron a los equipos de Java (de ambas oficinas, probablemente a 20 desarrolladores en total) a usar este formato, que ignoraba alegremente los 2 pilares del "debate de la llave" y se vuelve loco:

if ( x == y ) 
    {
    System.out.println("this is painful");
    x = 0;
    y++;
    }

Prohibido:

while (true) {

Permitido:

for (;;) {

un amigo mío, lo llamaremos CodeMonkey, consiguió su primer trabajo fuera de la universidad [hace muchos años] haciendo desarrollo interno en COBOL. Su primer programa fue rechazado por "no cumplir con nuestros estándares" porque usaba ... [¡estremecimiento!] Declaraciones IF anidadas

los estándares de codificación prohibieron el uso de declaraciones IF anidadas

ahora, CodeMonkey no era tímido y estaba seguro de sus habilidades, por lo que insistió en preguntar a todos en la cadena y en el pasillo por qué existía esta regla. La mayoría afirmó que no sabían, algunos inventaron cosas sobre 'legibilidad', y finalmente una persona recordó la razón original: la primera versión del compilador COBOL que usaron tenía un error y no manejaba correctamente las declaraciones IF anidadas.

Este error del compilador, por supuesto, se había solucionado durante al menos una década, pero nadie había desafiado los estándares . [baaa!]

CodeMonkey logró cambiar los estándares, ¡con el tiempo!

Una vez trabajó en un proyecto donde se prohibieron los guiones bajos. Y quiero decir totalmente prohibido. Entonces, en la aplicación ac # winforms, cada vez que agregamos un nuevo controlador de eventos (por ejemplo, para un botón) tendríamos que cambiar el nombre del método predeterminado de buttonName_Click () a otra cosa, solo para satisfacer el ego del tipo que escribió la codificación normas Hasta el día de hoy no sé qué tenía contra el humilde guión bajo

Convenciones de nombres de bases de datos totalmente inútiles. Cada nombre de tabla tiene que comenzar con un número. Los números muestran qué tipo de datos hay en la tabla.

• 0: datos que se usan en todas partes
• 1: datos que solo utiliza cierto módulo
• 2: tabla de búsqueda
• 3: calendario, chat y correo
• 4: registro

Esto hace que sea difícil encontrar una tabla si solo conoce la primera letra de su nombre. Además, como se trata de una base de datos mssql, tenemos que rodear los nombres de las tablas con corchetes en todas partes.

-- doesn't work
select * from 0examples;

-- does work
select * from [0examples];

Estábamos haciendo un proyecto en C ++ y el líder del equipo era un tipo Pascal.

Así que teníamos un archivo de inclusión estándar de codificación para redefinir toda esa sintaxis molesta de C y C ++:

#define BEGIN {
#define END }

¡pero espera hay mas!

#define ENDIF }
#define CASE switch

etc. Es difícil de recordar después de todo este tiempo.

Esto tomó lo que habría sido un código C ++ perfectamente legible y lo hizo ilegible para cualquiera, excepto para el líder del equipo.

También tuvimos que usar la notación húngara inversa, es decir

MyClass *class_pt  // pt = pointer to type

UINT32 maxHops_u   // u = uint32

aunque extrañamente me llegó a gustar esto.

En un antiguo trabajo:

• Las tablas "normales" comienzan con T_
• Las tablas del "sistema" (generalmente búsquedas) comienzan con TS_ (excepto cuando no lo hacen porque alguien no tenía ganas ese día)
• Las tablas de referencias cruzadas comienzan con TSX_
• Todos los nombres de campo comienzan con F_

Si, eso es correcto. Todos los campos, en cada tabla. Para que podamos decir que es un campo.

Un amigo mío encontró esta regla mientras trabajaba en un trabajo del gobierno. El uso de ++ (pre o post) fue completamente prohibido. La razón: diferentes compiladores pueden interpretarlo de manera diferente.

La mitad del equipo favoreció la sangría de cuatro espacios; la otra mitad favoreció la sangría de dos espacios.

Como puede adivinar, el estándar de codificación exigía tres, para "ofender a todos por igual" (una cita directa).

No poder usar Reflection ya que el gerente afirmó que involucraba demasiada 'magia'.

La más extraña que tuve, y que me llevó bastante tiempo derrocar, fue cuando el propietario de nuestra empresa exigió que nuestro nuevo producto fuera solo IE. Si podía funcionar en Firefox, estaba bien, pero tenía que ser solo IE.

Esto puede no sonar demasiado extraño, excepto por un pequeño defecto. Todo el software fue para un paquete de software de servidor a medida, que se ejecuta en Linux, y todas las cajas de clientes que nuestro cliente estaba comprando eran Linux. A falta de tratar de descubrir cómo poner en funcionamiento Wine (en aquellos días, muy poco confiable) en todos estos cuadros y ver si podíamos ejecutar IE y capacitar a sus administradores sobre cómo solucionar problemas de Wine, simplemente no era posible para cumplir con la solicitud del propietario. El problema era que estaba haciendo el diseño web y simplemente no sabía cómo hacer que los sitios web fueran compatibles con FireFox.

Probablemente no te sorprenderá saber que nuestra empresa se declaró en quiebra.

Usar nombres de identificadores numerados genéricos

En mi trabajo actual tenemos dos reglas que son realmente malas:

Regla 1: Cada vez que creamos un nuevo campo en una tabla de base de datos, tenemos que agregar campos de reserva adicionales para uso futuro. Estos campos de reserva están numerados (porque nadie sabe qué datos mantendrán algún día). La próxima vez que necesitemos un nuevo campo, primero buscaremos un campo de reserva no utilizado.

Así que terminamos con customer.reserve_field_14contener la dirección de correo electrónico del cliente.

Un día, nuestro jefe pensó en presentar mesas de reserva , pero afortunadamente pudimos convencerlo de que no lo hiciera.

Regla 2: Uno de nuestros productos está escrito en VB6 y VB6 tiene un límite del recuento total de diferentes nombres de identificadores y, dado que el código es muy grande, constantemente nos encontramos con este límite. Como "solución", todos los nombres de variables locales están numerados:

• Lvarlong1
• Lvarlong2
• Lvarstr1
• ...

Aunque eso efectivamente evita el límite del identificador, estas dos reglas combinadas conducen a un código hermoso como este:

...

If Lvarbool1 Then
  Lvarbool2 = True
End If

If Lvarbool2 Or Lvarstr1 <> Lvarstr5 Then
  db.Execute("DELETE FROM customer WHERE " _ 
      & "reserve_field_12 = '" & Lvarstr1 & "'")
End If

...

Puedes imaginar lo difícil que es arreglar el código antiguo o de otra persona ...

Última actualización: ahora también estamos utilizando "procedimientos de reserva" para miembros privados:

Private Sub LSub1(Lvarlong1 As Long, Lvarstr1 As String)
  If Lvarlong1 >= 0 Then 
    Lvarbool1 = LFunc1(Lvarstr1)
  Else
    Lvarbool1 = LFunc6()
  End If
  If Lvarbool1 Then
    LSub4 Lvarstr1
  End If
End Sub

EDITAR: Parece que este patrón de código se está volviendo cada vez más popular. Vea esta publicación de The Daily WTF para obtener más información: Astigmatismo :)

En mis días en C ++ no se nos permitía usar ==,> =, <=, &&, etc. Había macros para esto ...

if (bob EQ 7 AND alice LEQ 10)
{
   // blah
}

Obviamente, esto era para tratar con la "antigua asignación accidental en error condicional", sin embargo, también teníamos la regla "poner constantes antes que las variables", así que

if (NULL EQ ptr); //ok
if (ptr EQ NULL); //not ok

Recién recordado, el estándar de codificación más simple que escuché fue "Escribir código como si el próximo responsable de mantenimiento fuera un psicópata vicioso que sabe dónde vives".

Notación húngara en general.

He tenido muchas reglas estúpidas , pero no muchas que considere francamente extrañas.

El más tonto fue en un trabajo de la NASA en el que trabajé a principios de los 90. Este fue un trabajo enorme, con más de 100 desarrolladores. Los desarrolladores experimentados que escribieron los estándares de codificación decidieron que cada archivo fuente debería comenzar con un acrónimo de cuatro letras, y la primera letra debía representar al grupo responsable del archivo. Esta fue probablemente una gran idea para los viejos proyectos FORTRAN 77 a los que estaban acostumbrados.

Sin embargo, este era un proyecto Ada , con una estructura de biblioteca jerárquica agradable, por lo que no tenía ningún sentido. Cada directorio estaba lleno de archivos que comenzaban con la misma letra, seguidos por 3 letras más sin sentido, un guión bajo y luego parte del nombre del archivo que importaba. Todos los paquetes de Ada tuvieron que comenzar con esta misma verruga de cinco caracteres. Las cláusulas de "uso" de Ada tampoco estaban permitidas (posiblemente algo bueno en circunstancias normales), por lo que cualquier referencia a cualquier identificador que no fuera local para ese archivo fuente también tenía que incluir esta verruga inútil. Probablemente debería haber habido una insurrección sobre esto, pero todo el proyecto fue atendido por programadores junior y recién llegado de nuevas contrataciones universitarias (siendo yo el último).

Una declaración de asignación típica (ya detallada en Ada) terminaría pareciéndose a esto:

NABC_The_Package_Name.X := NABC_The_Package_Name.X + 
  CXYZ_Some_Other_Package_Name.Delta_X;

¡Afortunadamente estaban al menos lo suficientemente iluminados como para permitirnos más de 80 columnas! Aún así, la verruga de la instalación fue odiada lo suficiente como para que se convirtiera en un código repetitivo en la parte superior de los archivos de origen de todos para usar los "cambios de nombre" de Ada para deshacerse de la verruga. Habría un cambio de nombre para cada paquete importado ("marchito"). Me gusta esto:

package Package_Name renames NABC_Package_Name;
package Some_Other_Package_Name renames CXYZ_Some_Other_Package_Name;
--// Repeated in this vein for an average of 10 lines or so

Lo que los más creativos entre nosotros hicieron fue tratar de usar la verruga para crear un nombre de paquete agudamente sensible (o tonto). (¡Sé lo que estás pensando, pero los explosivos no estaban permitidos y la culpa es tuya! Eso es asqueroso). Por ejemplo, estaba en el grupo de código C ommon y necesitaba hacer un paquete para interactuar con el grupo W orkstation. Después de una sesión de lluvia de ideas con el chico de la estación de trabajo, decidimos nombrar nuestros paquetes para que alguien que necesitara ambos tuviera que escribir:

with CANT_Interface_Package;
with WONT_Interface_Package;

Cuando comencé a trabajar en un lugar y comencé a ingresar mi código en el control de fuente, mi jefe de repente se me acercó y me pidió que dejara de cometer tanto. Me dijo que no se recomienda hacer más de 1 confirmación por día para un desarrollador porque ensucia el control de la fuente. Simplemente lo miré boquiabierto ...

Más tarde entendí que la razón por la que incluso se me ocurrió al respecto es porque el servidor SVN le enviaría a él (y a 10 ejecutivos más altos) un correo por cada compromiso que alguien haga. Y al ensuciar el control de la fuente, supuse que había visto su buzón.

Realización de todas las consultas de la base de datos a través de procedimientos almacenados en Sql Server 2000. Desde consultas complejas de varias tablas hasta simples como:

select id, name from people

Los argumentos a favor de los procedimientos fueron:

• Actuación
• Seguridad
• Mantenibilidad

Sé que el tema del procedimiento es bastante controvertido, así que siéntase libre de calificar mi respuesta negativamente;)

Debe haber 165 pruebas unitarias (no necesariamente automatizadas) por 1000 líneas de código. Eso funciona en una prueba por aproximadamente cada 8 líneas.

No hace falta decir que algunas de las líneas de código son bastante largas y las funciones devuelven estos punteros para permitir el encadenamiento.

Tuvimos que ordenar todas las funciones en clases alfabéticamente, para hacerlas "más fáciles de encontrar". No importa que el ide tuviera un menú desplegable. Eso fue demasiados clics.

(El mismo líder tecnológico escribió una aplicación para eliminar todos los comentarios de nuestro código fuente).

En 1987, más o menos, trabajé en una empresa que me contrató porque era una de las pocas personas que sabían cómo usar Revelation. Revelation, si nunca has oído hablar de él, fue esencialmente una implementación basada en PC del sistema operativo Pick, que, si nunca has oído hablar de él, recibió su nombre de su inventor, el fabulosamente llamado Dick Pick. Mucho se puede decir sobre Pick OS, la mayoría es bueno. Varios proveedores de supermini (Prime y MIPS, al menos) usaron Pick o sus propias implementaciones personalizadas.

Esta empresa era una tienda Prime, y para sus sistemas internos utilizaban información. (No, ese era realmente su nombre: era la implementación de Pick de Prime.) Tenían un contrato con el estado para construir un sistema basado en PC, y habían dedicado aproximadamente un año a su proyecto Revelation antes de que el tipo hiciera todo el trabajo, quien también era su director de MIS, decidió que ya no podía hacer los dos trabajos y me contrató.

En cualquier caso, había establecido una serie de estándares de codificación para su software basado en Prime, muchos de los cuales se derivaban de dos condiciones básicas: 1) el uso de terminales tontas de 80 columnas y 2) el hecho de que desde Prime no No tengo un editor visual, él había escrito el suyo. Debido a la portabilidad mágica del código Pick, había llevado a su editor a Revelation y había construido todo el proyecto en la PC usándolo.

Revelation, por supuesto, basado en PC, tenía un editor de pantalla completa perfectamente bueno, y no se opuso cuando pasaste la columna 80. Sin embargo, durante los primeros meses que estuve allí, insistió en que usara su editor y sus estándares

Entonces, el primer estándar fue que cada línea de código tenía que ser comentada. Cada línea. Sin excepciones. Su razón para eso era que, incluso si su comentario decía exactamente lo que acababa de escribir en el código, tener que comentarlo significaba que al menos pensaba en la línea dos veces. Además, como señaló alegremente, había agregado un comando al editor que formateaba cada línea de código para que pudiera poner un comentario al final de la línea.

Oh si. Cuando comentaste cada línea de código, fue con comentarios de fin de línea . En resumen, los primeros 64 caracteres de cada línea eran para el código, luego había un punto y coma, y ​​luego tenía 15 caracteres para describir lo que hicieron sus 64 caracteres. En resumen, estábamos usando una convención de lenguaje ensamblador para formatear nuestro código Pick / Basic. Esto llevó a cosas que se veían así:

EVENT.LIST[DATE.INDEX][-1] = _         ;ADD THE MOST RECENT EVENT
   EVENTS[LEN(EVENTS)]                 ;TO THE END OF EVENT LIST

(En realidad, después de 20 años, finalmente he olvidado la sintaxis de continuación de línea de R / Basic, por lo que puede haber sido diferente. Pero se entiende la idea).

Además, cada vez que tenía que insertar comentarios multilínea, la regla era que usara una caja de flores:

************************************************************************
**  IN CASE YOU NEVER HEARD OF ONE, OR COULDN'T GUESS FROM ITS NAME,  **
**  THIS IS A FLOWER BOX.                                             **
************************************************************************

Sí, se requerían esos asteriscos de cierre en cada línea. Después de todo, si usabas su editor, era solo un simple comando de editor para insertar una caja de flores.

Lograr que cediera y me permitiera usar el editor incorporado de Revelation fue toda una batalla. Al principio fue insistente, simplemente porque esas eran las reglas. Cuando objeté que a) ya conocía al editor de Revelation b) era sustancialmente más funcional que su editor, c) otros desarrolladores de Revelation tendrían la misma perspectiva, él respondió que si no me entrenaba en su editor no lo haría nunca podría trabajar en la base de código Prime, que, como ambos sabíamos, no iba a suceder mientras el infierno permaneciera sin congelar. Finalmente se rindió.

Pero los estándares de codificación fueron los últimos en desaparecer. Los comentarios de la caja de flores en particular fueron una estúpida pérdida de tiempo, y luchó contra ellos con uñas y dientes, diciendo que si solo usara el editor adecuado, mantenerlos sería perfectamente fácil. (Todo se volvió bastante pasivo-agresivo). Finalmente cedí en silencio, y desde entonces todo el código que traje a las revisiones de códigos tenía sus preciosos comentarios de caja de flores.

Un día, varios meses en el trabajo, cuando me había demostrado más que competente (especialmente en comparación con el notable desfile de otros codificadores que pasaron por esa oficina mientras trabajaba allí), él estaba mirando por encima de mi hombro mientras yo funcionó, y se dio cuenta de que no estaba usando comentarios de caja de flores. Oh, dije, escribí un formateador de código fuente que convierte mis comentarios a tu estilo cuando los imprimo. Es más fácil que mantenerlos en el editor. Abrió la boca, pensó por un momento, la cerró, se fue y nunca más volvimos a hablar de normas de codificación. Nuestros dos trabajos se hicieron más fáciles después de eso.

En mi primer trabajo, todos los programas en C, por simples o complejos que fueran, solo tenían cuatro funciones. Tenías el principal, que llamaba a las otras tres funciones a su vez. No recuerdo sus nombres, pero eran algo similar a begin (), middle () y end (). begin () abrió archivos y conexiones de bases de datos, end () los cerró y middle () hizo todo lo demás . No hace falta decir que middle () fue una función muy larga.

Y solo para mejorar las cosas, todas las variables tenían que ser globales.

Uno de mis recuerdos más orgullosos de ese trabajo es haber sido parte de la revuelta general que llevó a la destrucción de esos estándares.

Un estándar de codificación C escrito externamente que tenía la regla 'no confíes en la precedencia del operador incorporado, siempre usa corchetes'

Justo, la intención obvia era prohibir:

a = 3 + 6 * 2;

en favor de:

a = 3 + (6 * 2);

La cosa fue que esto fue implementado por una herramienta que siguió las reglas de sintaxis de C que '=', '==', '.' y el acceso a la matriz son operadores. Entonces código como:

a[i].x += b[i].y + d - 7;

tuvo que ser escrito como:

((a[i]).x) += (((b[i]).y + d) - 7);