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

Hace poco vi que Microsoft lanzó un documento de estándares de codificación ( Estándares de codificación del marco de código todo en uno ) 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)?

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 sobre los estándares:

1. Déjelos evolucionar durante las primeras iteraciones.
2. Deje que sean específicos del equipo en lugar de específicos de la empresa.
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.

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 todo el código base sea mucho más fácil, ya que cambiar de estilo 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 utilizar un buen estilo si hay un estándar explícito, en lugar de uno implícito.
• Las convenciones de nomenclatura consistentes facilitan mucho la búsqueda de funciones / variables ¿Fue ArraySort o array_Sort o sortTheArray o doSortArray o ...?

En términos de adoptar o no 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.

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 código Java 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

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.

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, biblioteca y marco que estoy usando, para que un código fuente se vea uniforme y simple.

Tenga en cuenta que este es un documento de estándares de codificación que es específico del 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 las Pautas de diseño de marcos . 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 es inútil proporcionarles un documento de más de 50 páginas. 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.

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 brinda 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, StyleCop es una bala de plata. Si también está utilizando ReSharper, entonces el complemento StyleCop para ReSharper es simplemente increíble.

Somos una tienda de blub, por lo que utilizamos las convenciones de programación de 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 material de código abierto, el estándar del proyecto en el que estamos trabajando.

Necesitas un estándar. He visto diferentes estándares en diferentes rincones de una aplicación que tenían diferentes clientes potenciales 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.

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 va a 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 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 reglas nuevas. (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 copyright estándar en sus encabezados, ya que no desea ejecutar cada archivo nuevo que escriba ante el equipo legal de su empresa, y ciertamente desea obtener los nombres de cualquier API pública la primera vez