it-swarm-es.com

¿Su empresa tiene un estándar de codificación?

Hace poco vi que Microsoft lanzó un documento de estándares de codificación ( All-In-One Code Framework Coding Standards ) y me hizo pensar ... La compañía para la que trabajo no tiene estándares formales de codificación. Solo hay unos pocos desarrolladores y hemos estado juntos el tiempo suficiente para evolucionar a estilos similares y nunca ha sido un problema.

¿La empresa para la que trabaja tiene estándares de codificación documentados? Si no, ¿por qué no? ¿Tener un estándar hace la diferencia? ¿Vale la pena escribir un estándar desde cero o debería adoptar otro estándar como propio (es decir, hacer que los estándares de Microsoft sean suyos)?

31
Walter

Es importante que un equipo tenga un único estándar de codificación para cada idioma para evitar varios problemas:

  • La falta de estándares puede hacer que su código sea ilegible.
  • El desacuerdo sobre los estándares puede causar guerras de registro entre desarrolladores.
  • Ver diferentes estándares en la misma clase puede ser extremadamente irritante.

Soy un gran admirador de lo que el tío Bob tiene que decir acerca de los estándares:

  1. Déjelos evolucionar durante las primeras iteraciones.
  2. Permítales ser específicos del equipo en lugar de específicos de la compañía.
  3. No los escriba si puede evitarlo. Más bien, deje que el código sea la forma en que se capturan los estándares.
  4. No legisles un buen diseño. (por ejemplo, no le digas a la gente que no use goto)
  5. Asegúrese de que todos sepan que el estándar se trata de comunicación y nada más.
  6. Después de las primeras iteraciones, reúna al equipo para decidir.
39
Paddyslacker

Creo que es esencial tener un estándar de codificación, incluso si todo lo que dice es "usamos sangría de 3 espacios y los corchetes van a la siguiente línea". Algunos beneficios:

  • Hace que la lectura de toda la base de código sea mucho más fácil, ya que cambiar entre estilos de codificación entre archivos es molesto.
  • Facilita la lectura de un solo archivo, ya que cualquier archivo actualizado por dos desarrolladores con estilos en conflicto eventualmente tenderá a mezclar esos estilos. Leer un archivo que mezcla pestañas y espacios (y editarlo más tarde) es un fastidio.
  • Facilita a los nuevos desarrolladores usar un buen estilo si hay un estándar explícito, en lugar de uno implícito.
  • Las convenciones de nomenclatura consistentes hacen que sea mucho más fácil encontrar funciones/variables. ¿Fue ArraySort o array_Sort o sortTheArray o doSortArray o ...?

En términos de adoptar un estándar existente, en realidad no importa, lo importante es la consistencia. Si sus desarrolladores tienen una docena de estilos diferentes, también podría elegir uno existente, publicado. Si todos han evolucionado hacia un estilo bastante consistente, solo anótelo y úselo.

8
Fishtoaster

No estoy de acuerdo con "somos una tienda X", por lo que formateamos nuestro código en todos los idiomas de la misma manera.

Personalmente, he descubierto que la mayoría de los idiomas tienen diferentes estilos aceptados.

Realmente no puedo soportar cuando los programadores de C escriben Java código con formato de C. No solo no se parece a Java, sino que los engaña haciéndoles creer que pueden usar otras prácticas similares a C en Java.

Creo que si tienes un estándar debería ser por idioma

5
sylvanaar

Mi antiguo empleador tiene un estándar de codificación. Estoy considerando documentar formalmente uno para mí también.

O, como sugiere, encontrar un estándar existente decente y modificarlo/adoptarlo. Para una empresa, ciertamente sugeriría que analicen los estándares de codificación existentes, pero creen/modifiquen uno para sus propias necesidades particulares. No es necesariamente necesario crear uno desde cero, pero se debe tener cuidado para asegurarse de que el estándar de codificación tenga sentido para el tipo de software que crea la empresa.

Sí, tener un estándar de codificación hace la diferencia, pero no es una bala de plata. El código es más legible ya que no hay tantos choques de estilos diferentes y se pueden evitar algunos errores/trampas comunes. Incluso con un estándar, tendrá alguna variación en los estilos de codificación, pero esa variabilidad se reducirá. El objetivo no es tratar de evitar toda variación o prepararse para cada situación posible. Un estándar de codificación demasiado complicado puede ser peor que ninguno.

2
George Marian

Lamentablemente no. Por lo tanto, todos tienen su propia forma de usar el espaciado, la sangría, etc., todo mezclado (de esta manera, ¡ni siquiera tenemos que usar la función de "culpa" para saber quién es el autor de una línea de código!)

Pero, lo que es peor, alguien escribe nombres de variables y clases en italiano, alguien más en inglés ...

Siempre adapto mi estilo al del lenguaje, la biblioteca y el marco que estoy usando, para que un código fuente se vea uniforme y simple.

1
Wizard79

Tenga en cuenta que este es un documento de estándares de codificación que es específico para el Marco de código todo en uno.

He trabajado en varias compañías, algunas de las cuales tenían un estándar existente y algunas (la mayoría) de las cuales ayudé a desarrollar el estándar. En su mayor parte, si está haciendo un desarrollo basado en .NET (e incluso si no lo hace, la mayoría de las reglas aún se aplican), debería echar un vistazo a Pautas de diseño del marco . Si bien esto es específico para escribir API públicas, la mayoría de las pautas se aplican igualmente bien a cualquier código.

La mayor preocupación con los estándares de código es mantenerlo relativamente simple y directo. Desea que los desarrolladores puedan internalizar las pautas presentadas, por lo que darles un documento de más de 50 páginas es inútil. Todavía puede crear ese documento si desea proporcionar antecedentes, ejemplos, etc. pero también querrá algo que se reduzca a un conjunto de pautas con viñetas. Su estándar de codificación también tiene que ser un documento flexible y vivo que deba cambiar a medida que la tecnología cambie.

1
Scott Dorman

Necesitas un estándar. He visto diferentes estándares en diferentes rincones de una aplicación que tenían clientes potenciales diferentes que todos querían hacerlo "a su manera". Quizás el concepto de "estándar" fue mal entendido. Muy loco. Y, los peores estándares son generados por una persona. No importa quién sea esa persona, si una persona sola desarrolla el estándar, es casi seguro que sea malo.

1
anon

Puede ayudar a las personas, también puede ayudar realmente con las herramientas:

Si desea poder usar cualquier tipo de formato de código automático, realmente necesita estandarizar las reglas que usará, de lo contrario, recibirá constantemente muchos cambios de formato sin sentido que saturan sus diferencias.

Los conjuntos de reglas predeterminadas para las herramientas de análisis estático bien pueden verificar un estilo de nomenclatura específico, y es probable que sea más fácil adaptarse a eso y luego escribir un montón de nuevas reglas. (a menos que vaya a desactivar la regla por completo)

por último, es bueno estandarizar todo lo que necesita ser consultado con alguien fuera de su equipo. es decir, es probable que desee un aviso de derechos de autor estándar en sus encabezados, ya que no desea ejecutar todos los archivos nuevos que escribe sobre el equipo legal de su empresa, y ciertamente desea obtener los nombres de cualquier API pública la primera vez

1
jk.

Las discusiones estándar de codificación se reducen a esto:

  • Sí, los necesita, la consistencia y el código limpio son la piedra angular del buen desarrollo.
  • Lo que son casi no importa, siempre y cuando todos sigan los mismos estándares.
  • No escriba el suyo, terminará en una discusión interminable y dolorosa. Hay muchos por ahí que son populares.
  • El uso de estándares públicos (como los de MSDN ) le proporciona un tercero agnóstico con el que no se puede discutir. Si quiere discutir con ellos, consulte el punto 2.

Si está desarrollando en C # en Visual Studio, entonces StyleCop es una bala de plata. Si también está utilizando ReSharper, entonces el complemento StyleCop for ReSharper es simplemente increíble.

1
dwynne

Somos una tienda blub, por lo que utilizamos las convenciones de programación blub.

Ahora Paul Graham y sus amigos son mucho más inteligentes que nosotros, pero nosotros, los programadores de blub, todos podemos leernos mutuamente, de hecho, cualquier programador de blub puede leer nuestro código de blub.

De hecho, debido al diseño de blub, cualquier programador de blub puede leer cualquier archivo blub y comprenderlo, porque blub no tiene un sistema macro.

Si programamos en say, C o C++ (todos somos multilingües, a pesar de que programamos en blub), usamos principalmente estilo blub para código nuevo o para código abierto, el estándar del proyecto en el que estamos trabajando.

1
Tim Williscroft