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


77

¿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


44
He hecho una pregunta similar (pero no exactamente la misma) sobre SO antes por cierto: stackoverflow.com/questions/218123/…
Brian R. Bondy

@Brian, gracias, había visto tu pregunta pero la había olvidado.
finnw

44
El verdadero problema con los estándares de codificación es el tiempo y el esfuerzo desperdiciados discutiendo si son correctos o no. Nada supera a una buena guerra entre
llaves

Respuestas:


97

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.


12
Encuentro (al menos ahora, antes en la escuela que parecía extraño) que comentar en conjunto es una mala práctica
Shady M. Najib

14
No solo eso, sino que descubrí que la sobrecarga asociada con la creación de un nuevo archivo de clase cuando tienes que poner una carga de repeticiones en la parte superior realmente disuade a los desarrolladores de crear nuevas clases y fomenta enormes clases difíciles de manejar y, por lo tanto, un mal diseño.
Gaz

13
¡Discrepar! ¡No agregamos información inútil o de información, sino una explicación textual real de lo que hace la función (en el archivo .h) y es muy útil! Por supuesto, estamos comprometidos a mantenerlo sincronizado con el código.
Asistente

55
@Shady M Najib, ¿siempre es malo o malo cuando se le permite pasar sin control / sin mantenimiento? En general, un buen código hará que su propósito sea lo suficientemente obvio para evitar la necesidad de comentarios, pero ese no es siempre el caso y creo que en estos escenarios los comentarios son cruciales. No puedo pensar en una mala razón para incluir comentarios XMLDoc.
Nathan Taylor el

77
Un bloque que explica lo que hace es bueno. Un bloque que simplemente repite los tipos y nombres de los argumentos y el valor de retorno es malo. Cuando tuve que trabajar con un estándar que ordenaba este último, escribí un script de emacs para generar automáticamente la mayoría.
AShelly

130

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.


10
¿No es solo para que el profesor sepa que sabes exactamente lo que está pasando?
John MacIntyre

80
Creo que está claro lo que está pasando, y no es educación.
Dan Ray

18
El ejemplo que tiene arriba es claro, pero ¿qué pasa si un estudiante copia alguna llamada de función desde otra aplicación o un libro o lo que sea, y realmente no lo entiende? ¿Cómo lo sabrá el profesor? Esta estúpida regla no permite ningún área gris (que en su defensa, probablemente se haya abusado antes). Así es como interpreto esto. ... importa si vi esto en un entorno no académico, podría asustarme un poco. ;-)
John MacIntyre

44
Sí, excepto que siempre puedes escribir comentarios que solo repitan el código y no muestren ningún entendimiento. ¿Te hace correcto "// Ending Brace" antes del final de la llave?
alternativa

66
¿Qué pasa si accidentalmente tienes un comentario útil en tu código? ¿Necesitas poner // commenten la línea antes de eso?
configurador

103

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.


11
Traté de votar esto una docena de veces ...
TGnat

22
Si crees que necesitas #REGION, creo que necesitas refactorizar.
Jay Bazuzi

23
Generalmente organizo el código por regiones en constructores, propiedades, eventos, métodos y miembros. Hace que administrar y navegar por la fuente sea muy fácil (especialmente en algunas clases de utilidades estáticas que pueden crecer bastante). Sin embargo, no los usaría más que eso.
Evan Plaice

26
Tenemos un estándar de codificación simple: nunca anidar regiones. Solo utilícelos para agrupar métodos relacionados (inicialización, serialización, propiedades, etc.)
Jason Williams

66
El único buen propósito de #regions es ocultar el código que no necesita ser editado . Eso podría ser código generado, o código con un algoritmo difícil de entender que preferiría que la gente no tocara, o tal vez bloques de código de depuración feos. Pero no es un código en el que la gente estará trabajando. Para aquellos atrapados en una tienda #region, tengo una macro que colapsa en definiciones pero expande regiones. Ver aquí: stackoverflow.com/questions/523220/awesome-visual-studio-macros/…
Kyralessa

80

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)


14
Lo sentimos, pero qué sucede cuando refactoriza la base de datos o cuando decide que la longitud de VARCHAR debe ser diferente. De repente, tienes que revisar todo tu código y cambiar ... oh dios. Eso se ve horrible.
Tom Morris

71
No hay vocales ?? ¿Estás bromeando no?
Daniel Cassidy

39
¿Las personas que hicieron cumplir esta norma tenían crestas en la frente y a menudo hablaban de honor y batalla?
Ryan Roberts

10
Jaja, bueno, eran DBA, así que ...;)
Damovisa

14
Debería haber enviado los nombres de sus columnas a través de un acortador de URL. PersonFirstNameVarchar30NotNull = bit.ly/cULlQc
Billy Coover el

48

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

21
Más enviable: si necesita un comentario para decir cuál fue el inicio del bloque, entonces el bloque es demasiado largo o su contenido es demasiado complejo => refactorizar.
Richard

55
Quiero votar en contra, porque los bloques largos y profundamente anidados pueden ser difíciles de resolver, y estos comentarios pueden ayudar. Quiero votar, porque esos comentarios se volverán incorrectos (y muy confusos) muy pronto, y porque los bloques largos y profundamente anidados son una señal de que necesita refactorizar, no agregar más comentarios.
Jay Bazuzi

77
Esa fue una gran idea para un mundo sin IDE poderoso.
IAdapter

99
@Jay en cualquier IDE decente, puede resaltar una llave y resaltará la otra llave correspondiente. Yo personalmente odio cuando la gente hace esto.
Evan Plaice

3
Si bien su ejemplo es un poco loco (ya que no son lo suficientemente largos como para que importen y lo retrasen al cambiar la lógica), esto no siempre es algo malo. Comentarios como ese son realmente útiles para cerrar espacios de nombres / declaraciones endif que abarcan un archivo completo.
jsternberg

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

'Nuff dijo.


99
¿No incluiría <iso646.h> una opción mucho mejor?
AndrejaKo

3
@AndrejaKo: esto es anterior a <iso646.h>; Esto fue un intento de hacer que C parezca FORTRAN.
Niall C.

2
¿Era realmente un estándar de codificación? es decir, ¿existía una política de la empresa contra la escritura directa de los operadores?
finnw

21
¿También tenía #define BEGIN {y #DEFINE END }?
JBRWilkinson

3
Eso me recuerda a un artículo de Daily WTF que vi que tenía un programador de C ++ que tenía un montón de definiciones para que pareciera Visual Basic (o tal vez solo Basic, algún dialecto). #define void Sub, #define} Fin, cosas así.
Wayne Molina

37
  • 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".

3
+1. Las molestias menores se suman. También son difíciles de discutir porque el editor de estándares de codificación o PM puede decir "No es una gran carga, por lo que no vale la pena cambiarlo".
finnw

1
Exactamente. (Aunque en este caso, leer innumerables nombres variables como este realmente puede ser una gran carga).
John Siracusa

57
Diviértete inventando nombres que se analizan de dos maneras. pagehits, penisup, etc.
Jay Bazuzi

44
@Jay * sexchange
configurador

2
@configurator: Cuando el equipo de depuración de Visual Studio estaba trabajando en una función para permitirle ver la excepción actualmente en vuelo en la ventana de observación, iban a agregar una pseudo-variable llamada "$ ex". No nos dimos cuenta por mucho tiempo. Luego cambiamos el nombre a "$ excepción", pero todavía lo leo como "s".
Jay Bazuzi

36

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).


él nunca podría oír la palabra 'refactoring'
Nanda

3
Nunca escuchó muchas otras palabras ...
Wizard79

Así usted no necesita pruebas formales porque nunca se cambien los métodos ...
configurador

36

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.

2
Tenemos algunas personas en este campamento en mi lugar de trabajo. Es divertido cuando intentan jugar la carta de rendimiento y demostrar cuán desactualizados están sus conocimientos
Vuelva a instalar Mónica el

3
espera ... con toda seriedad, pensé que los SP ERA mejor, en términos de rendimiento, que las llamadas SQL directas de, digamos, C #?
Sk93

3
Parece que sabes exactamente por qué se incluyeron. : P
Mason Wheeler

44
Cuando crecí, finalmente entendí por qué todo debería pasar por el DB :) Con toda seriedad, esto simplifica tantas cosas, no intentes reinventar la rueda.
Jé Queue

3
He escuchado el razonamiento encantador "No podemos usar un OR / M porque toda interacción debe usar SP". Qué desperdicio de mano de obra.
configurador

33

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.


55
La única vez que escuché de alguien que no usaba el STL porque no era lo suficientemente rápido y tenía razón, era para juegos. EA hizo su propia implementación de STL para sus juegos. Dudo mucho que importe más (los juegos modernos tienen GPU limitada) y dudo que lo usen. Pero aún así, fue una implementación de STL, no una biblioteca completamente nueva. Aún usabas el STL cuando usabas EASTL.
Matt Olenik

1
@Matt: para agregar a esto, la queja de EA se centró en el uso de la memoria y la inicialización. Su propia implementación consumió menos memoria, la lanzó antes y evitó inicializar objetos que se inicializarían más tarde.
Matthieu M.

Le diría que lo codifique él mismo.
derecha el

31

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}

55
Ow ow ow ow ow ow!
Vuelva a instalar Mónica

22
El mayor problema con esta muestra son los nombres de variables sin sentido. Elimine los prefijos húngaros y algunos de ellos tienen 1 o incluso 0 caracteres de longitud.
finnw

8
Este es el sistema húngaro, que es útil en idiomas de tipo débil (ya que codifica la información de tipo que es crítica para trabajar en estos idiomas en los nombres); es inútil en idiomas fuertemente tipados. La mejor alternativa para los idiomas fuertemente tipados es Apps Hungarian, que codifica información importante sobre el uso de una variable (miembro, puntero, volátil, indexador), algo para lo que el idioma en sí no ofrece soporte.
Jason Williams

55
Oh por favor. Nunca he confundido a un local con un miembro, y no uso ese húngaro tonto para miembros / locales / campos / lo que sea. Creo que podrían ser útiles para diferenciar entre diferentes tipos de cadenas, como 'seguro' e 'inseguro', como el ejemplo de Joel en Hacer que el código incorrecto
configurador

3
@configurator: el ejemplo de Joel es horrible, sería mejor tener diferentes tipos, entonces el compilador haría cumplir el uso.
Matthieu M.

28

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


93
Una vez trabajé en un lenguaje que requería que cada variable - CADA variable - tuviera el prefijo "$".
Nohat

66
@nohat: Y te diste cuenta de que era increíble, ¿no?
Josh K

Una vez trabajé en un lenguaje donde todas mis variables comenzaron con signos de puntuación como '$' o '%' o '@'. Todavía lo hago, de vez en cuando.
David Thornley

3
Esto solo se convierte realmente en un problema cuando se requiere poner un fantes de funciones, entonces su código es verdaderamente fUcked (vUp).
Joe D

1
Suena como varias versiones de Perl ...

26

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.


2
Esta es una política horrible. Espero que este gerente haya sido enlatado.
Bernard

@ Bernard-En la mayoría de las organizaciones, la creación de un flujo de ingresos a largo plazo es motivo de una rápida promoción. Con suerte, alguien más vio la locura en esto y accidentalmente lo atropelló en el estacionamiento.
Jim Rush

24

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.


13
' Validations the handler' - uh-oh
Eric

8
+1 Ugh, odio esto. Creo que si estás utilizando software para generar comentarios, entonces no los necesitas.
bleevo

99
No creo que esta sea una mala regla. Al leer un método que tengo que mantener por primera vez, ayuda mucho si tengo especificaciones para todos los argumentos. Normalmente hay sutilezas (por ejemplo, qué sucede si el argumento es nulo, qué pasa si es una colección vacía, el nombre de un archivo inexistente, etc.) Otra buena regla (en mi humilde opinión) es que los nombres de los métodos deben ser verbos, pero en su ejemplo es un sustantivo.
finnw

3
@finnw Creo que es una buena práctica, pero un mal estándar. Si los desarrolladores están a bordo y escriben comentarios de métodos significativos cuando están justificados (detalles de excepción, etc.), eso es genial. Si no, terminas con un gran desastre. Y en el primer caso, no necesita una aplicación de nivel de compilación en absoluto.
Adam Lear

77
Caso clásico de indocumentación. Los comentarios que no dicen nada aparte de lo obvio deben ser eliminados a la vista.
Cumbayah

23

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.


66
¿Y nadie lo sabía svn log?
Htbaa

1
Los que iniciaron la política se habían ido hace mucho tiempo y los que siguieron la mantuvieron. Comencé en la misma semana que el nuevo CTO (amigo mío) y los dos miramos esto y dijimos WTF?
Jim A

20

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?


3
He estado eliminando muchos códigos comentados recientemente recientemente.
CoderDennis

2
Por lo general, elimino el código comentado a menos que esté acompañado de una buena explicación de por qué está comentado y por qué debe mantenerse en su lugar.
Jeremy Wiebe

Estoy totalmente de acuerdo. Comentar el código siempre que trabaje con él está bien, pero todo lo que entra en una versión de lanzamiento / rama principal debe estar vacío de código comentado. Alguien me dijo que "les gustaba saber cómo se podía hacer de manera diferente". Simplemente me resulta irritante por las razones mencionadas: ¿Es eso obsoleto, una solución alternativa, otra forma de hacerlo? WTF
Anne Schuessler

Con VS2013 "Peeks", todo esto está fuera de la ventana. Pero ponemos un comentario que dice "Ecuación modificada - Iniciales" o algo así, por lo que alguien se pregunta qué aspecto tendría el antiguo código en TFS / VCS si fuera necesario. Entonces, es una línea en lugar de 10 líneas comentadas. Pero VS2013 es increíble, muestra la historia de TFS allí para usted.
Suamere

17

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.


16

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.


Eso es bastante atroz
Evan Plaice

55
Mmm Dim Sum ...
configurador

Hice esto, antes de tener el control de la fuente, por supuesto. Una vez que teníamos el control de la fuente, era un hábito, prácticamente necesitábamos una intervención para que el equipo dejara de hacerlo. Finalmente, detuvimos y eliminamos todos los existentes cuando los encontramos.
Scott Whitlock

Nuestro desarrollador principal todavía trata de obligarnos a hacer esto. Ignoro la política cada vez que creo que puedo salirse con la suya (y a veces cuando sé que no puedo).
Joshua Smith

Tenemos un tipo en nuestro equipo que todavía hace esto en todas partes (también incluye cosas enormes de "Registro de cambios" en nuestros scripts SQL que también están bajo control de versiones). El argumento, como se me explicó, es que después de algunos cambios / confirmaciones, no recuerda la fecha en que se cambió algo, por lo que el registro de cambios es bueno para notar de inmediato quién cambió qué y por qué cuando abre un archivo.
Wayne Molina

14

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);
}

1
¿Les preguntaste por qué ? Me encantaría saber su motivación ...
JBRWilkinson

1
Wow, ¿por qué ese tipo incluso usa clases ?
Mateen Ulhaq

9

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


2
¿Cómo estuvo esto mal?
Jay Bazuzi

1
¿Porque entonces cada línea tiene 4 espacios innecesarios al principio?
nohat

Oh Ahora lo entiendo.
alternativa

21
Sí, StackOverflow tiene un estándar de codificación realmente malo. :-)
P Shved

Las sangrías grandes lo obligan a mantener bajo el nivel de anidación del código. He visto sangrías de 8 y funcionó bien.
Toon Krijthe

9

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.


Ese es un horrible, horrible estándar de codificación a tener que seguir. ¡Y una razón estúpida para ello también!
gablin

44
Si necesita desplazarse horizontalmente (por ejemplo, más de media página), probablemente también haya algo mal. Ninguna sangría tampoco es buena ya que hace que el código sea completamente ilegible. Trato de mantener un límite de 78 col, pero si es necesario superar esa cantidad, no me importa, pero trato de evitarlo.
Htbaa

8

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".


77
No te burles de los dinosaurios mayores, por favor. Ellos hicieron posible.
P Shved

44
Suena como seguridad laboral.
MIA

77
Tener un marcador de audio para saber cuándo se imprime cada archivo es ingenioso. Voy a agregar \07al inicio de cada archivo ahora.
configurador

2
El uso de un esquema de nomenclatura como este (no en mayúsculas) tenía algún sentido ya que las reglas de "alcance" variables de dBase eran inexistentes. Todo fue efectivamente global. Un iutilizado para indexar una matriz en un procedimiento podría interferir con un iprocedimiento de llamada. Debe usar PRIVATE ALL LIKE m*y PRIVATE ievitar este "sombreado"
Gerry

8

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.


¿Alguna de las compañías sigue funcionando hoy?
finnw

El que 'se movió' de Java es, el otro hace mucho que se fue. Nunca sobrevivieron al cambio de TRS-80 a una PC.
David B

6

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!


Bueno, como dice "Will", "antepongo el guión bajo para que mis variables privadas se agrupen en mi intellisense. Sin embargo, solo hago esto para las variables con alcance a un tipo. Variables declaradas dentro de un método o alcance más estrecho dejo el guión bajo desactivado. Hace que sea fácil mantenerlos separados y mantener juntas las variables menos utilizadas ". Y tengo que estar de acuerdo con él.
7wp

1
No creo que agrupar sus variables en su IDE propietario favorito sea una razón suficiente para desfigurar todo su código.
Adam Harte

Si es su código, hacer que sea utilizable en su IDE parece completamente razonable. Además, anteponer guiones bajos es común en muchos idiomas, por lo que cada vez que las personas lo ven, saben lo que significa.
rjmunro

1
+1 Usar un buen IDE (uno que pueda usar la búsqueda de expresiones regulares ) tiene más sentido para mí. Scratch IDE, aprenda a usar un editor de texto y terminal y será un programador mucho mejor. Como nota al margen, no me gustan particularmente los sigilos perl, pero al menos tienen un uso, a diferencia de los PHP.
alternativa el

66
Suspiro ... otra de esas personas "IDE son para coños".
Nailer

6

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.


6

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.


6

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!


99
Sería difícil devolver algo de una función declarada como nula.
Mircea Chirea

77
@MAttB Considere bajo qué condiciones se elsetomaría la rama final ( ).
Richard

66
else {return string.Empty; } se ejecutará cuando las 2 líneas anteriores hayan sido editadas por un desarrollador de mantenimiento dentro de 5 años. Sin embargo, devolver string.Empty ocultará el hecho de que solía ser una condición imposible . En su lugar, debería lanzar InvalidOperationException ("Este código no fue compatible con la lógica de tres valores");
MatthewMartin

1
Esto es horrible ¿Qué tiene de malo return verbose ? someString : someOtherString;?
Callum Rogers

1
@callum El operador ternario podría estar prohibido :) estado allí antes ...
hplbsh

6

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ó.


"No uses nombres confusos" me parece bastante justo ...
8128

1
Es absolutamente una directriz justa. Mi punto era que él no lo siguió en absoluto. Supongo que su idea de "no confundir" y la mía eran diferentes.
Ben Doom el

4

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."

66
¿Qué estaba mal con el HeapSort del líder del proyecto?
7wp

44
En realidad, si el código acepta la entrada externa del usuario, QuickSort puede estar equivocado ya que se abre a O(n^2)los ataques de DOS (alimentando la entrada del peor de los casos). También por qué no fue posible cambiar, ya que era una excusa válida para no usar STL.
Maciej Piechotka

4

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;
}

Muy similar a esta respuesta anterior .
finnw

Si. Todo lo que estoy obligado a comentar miembros privados también. Lo que tiene aún menos sentido.
Carl Bergquist

Animado a usar ghostdoc ?! Gah
configurador
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.