2008-10-07 11 views

Respuesta

5

Si se refiere a Directrices de estilo: un documento de Word o PDF. IMO, esto es algo "inamovible", pero por proyecto (si ve algo que no funciona, corríjalo para el próximo proyecto, especialmente si es tarde en el proyecto y tiene una tonelada de código que sigue el estilo existente).

1

Nuestro proyecto está principalmente en python, así que básicamente tomamos el Python Coding Guidelines, cambiamos algo aquí y allá que no nos gustó, y los metimos en nuestra wiki Trac. Está vinculado directamente en la página principal para que los desarrolladores sepan dónde encontrarlo. ¡Hasta ahora, realmente ha hecho un trabajo bastante decente de seguimiento!

1

Las pautas del código son un documento de toda la empresa que describe las prácticas. Y está disponible y debe ser seguido estrictamente.

El formato de código estándar está sujeto a la decisión de un miembro del equipo (o proyecto). Para nuestro proyecto, se mantiene en SVN como un conjunto de configuraciones para el complemento Resharper.

11

Utilizamos nuestro código para documentar el estándar. Esto, junto con la aplicación de los ingenieros principales/líderes, ha funcionado de maravilla para nosotros. La razón por la que no mantenemos un documento real es porque descubrimos que nadie lo lee y se vuelve obsoleto bastante rápido.

En mi humilde opinión todo lo que se necesita para demostrar el punto es el código existente que muestra el estilo/estándar.

Luz de viaje!

1

Para el proceso inicial, una wiki preparada con subtítulos es útil para recopilar opiniones de varios desarrolladores. Una vez que se ha recopilado la retroalimentación, se puede ordenar y "publicar".

ACTUALIZACIÓN:

Unos pocos años después, y Google Docs ahora sirve como una especie de wiki.

1

que documentan el estándar de código por:

estructura
  • del estilo general más importante (como la sangría, el ajuste de línea, llaves, ...)
  • a los detalles menos visibles (espacio antes/después ( o ))
  • ejemplos de código
  • descripciones de configuración para configurar el formateador de código Eclipse
  • prosa
4

Cuando he sido responsable de establecer un estándar de codificación, intento encontrar uno bueno en internet que se adapte a nuestras necesidades y lo use. Tomaré cualquier formato que aparezca, generalmente PDF o Word.

No tiene sentido reinventar la rueda; también puedo aprovechar el arduo trabajo que alguien más ha hecho.

1

Cuando gestioné un equipo pequeño, nuestros "estándares de codificación" eran un script de envoltura en CVS que ejecutaba sangría (con un archivo rc para todo el equipo) en su código cuando lo registraba.

1

Un sitio web interno con SVN utilizado para gestionar los cambios funciona. El 'último' está siempre disponible para el equipo en línea.

5

Lo ponemos en la wiki, con enlaces a fragmentos de código donde esto es útil.

Luego, configuramos un formateador de código en Eclipse para que coincida lo más posible con este estándar de codificación, aunque eso no puede ayudar con las mejores metodologías de codificación.

2

Creo que la mejor manera es utilizar Checkstyle para hacer cumplir su estándar de codificación y asegurar que la compilación falle si algunos códigos algo en contra de las reglas de estilo de control.

A continuación, utiliza la revisión de código y la programación en parejas jóvenes para que puedan aprender de las personas mayores

Usted podría también configurar una página wiki.

6

La única manera efectiva de publicar un estándar de codificación en mi opinión es integrarlo en el ide utilizado por los desarrolladores (eclipse o idea, por ejemplo). Por lo tanto, el nuevo código seguirá los estándares de manera predeterminada y el código antiguo se podrá reformatear utilizando ide.

Sólo unos pocos desarrollador leerá los estándares de codificación, un menor número de ellos van a usar después ...

7

Si está desarrollando en .NET. Recomendaría usar StyleCop para verificar tus compilaciones. También recomendaría usar ReSharper y el plugin StyleCop.

Con ReSharper y el plugin StyleCop obtiene líneas rojas "onduladas" en el código que está en contra del estándar y un simple mouse sobre explicará por qué. Sin revisiones de código, no hay documentos para maintian.

El uso de StyleCop en su proceso de compilación garantizará que todo el código registrado se ajuste a los estándares.

1

Pasamos de documentos de Word, que resultó ser engorroso y propenso a convertirse en obsoletos a

  • páginas wiki con las normas y ejemplos
  • automática de codificación de herramientas de validación estándar que se ejecutan durante el proceso de CI

NB También tenemos un cliente que no usa ejecutar nada aparte de la compilación en sí en el ciclo de CI. Mantienen sus reglas en ReSharper y están bastante satisfechos con los resultados

1

Si está utilizando Eclipse, puede usar formateadores (Preferencias-> Java-> Estilo de código-> Formateadores) para formatear automáticamente el código cuando el archivo fuente está salvado. Simplemente tenemos el formateador de nuestra compañía disponible en nuestra wiki y todo el mundo lo importa en Eclipse.

Lo bueno de los formateadores es que puedes decidir cuál quieres usar para que puedas tener diferentes proyectos con diferentes formatos. Sin embargo, normalmente solo usamos un formato, por lo que nuestro código es uniforme en todos los proyectos.

2

se utiliza la siguiente:

  1. Herramientas/plugins en el editor (Checkstyle, herramientas PMD, en la casa)
  2. cheques tiempo de construcción elaborar un informe.
  3. La wiki se utiliza para documentar los comentarios de revisión de código
  4. A partir del 3, a continuación, refactorizamos los 'aplicables' en la herramienta interna.
1

Depende de las circunstancias:

trabajé en una pequeña empresa con sólo tres desarrolladores. Ahí, solo lo discutimos. Esto significa nada más que preguntarle a sus codesarrolladores si tiene dudas sobre el estilo de codificación. Después de un tiempo, alguien se dio cuenta de que las mismas preguntas se le hicieron varias veces y abrió una página estándar de codificación en nuestro wiki.

Hoy trabajo en un pequeño laboratorio de investigación. En este campo particular, no tenemos normas de codificación formales. Sin embargo, como trabajamos en equipos y hacemos sesiones de par regularmente, un estándar de codificación implícita parece aparecer de la nada.


de algunos amigos, que desarrollan sistemas para la orientación de las aeronaves, sé que que están de acuerdo con las normas de codificación basado en

  • seguridad y gubernamentales restricciones
  • necesidades e insumos del departamento de control de calidad
  • si todavía hay libertad de elección: entrada de los desarrolladores

Este estándar de codificación está anotado y se aplica por QA.

1

Actualmente tenemos el estándar de codificación en una Wiki que solo los desarrolladores sénior tienen derecho a editar. Sin embargo, como muchas personas ya han indicado, nadie lo lee después de sus primeros días. Actualmente estamos en el proceso de tratar de obtener nuestro estándar de codificación en StyleCop en el lado .NET. Las cosas de Delphi son un poco más difíciles ya que no tenemos un marco Delphi como StyleCop para usar.

1

que hacer todo para que sea fácil de aplicar para todos:

  • en primer lugar, todo el equipo debe acordar la aplicación de ellas
  • Comparto la configuración para los editores usados ​​(gvim, emacs .. .)
  • proporciono archivo fuente vacío con la rúbrica del texto modelo
  • I sumarize el estándar en una sola hoja referencia, no mostrando los reglas, pero una pieza de código correctamente formateado como Stan dardized
2

Hemos hecho lo siguiente para documentar nuestros estándares de codificación:

  1. las escribió en un archivo de Word sin formato. La base para esta guía de estilo fueron las Convenciones de Codificación del Sol.
  2. Checkstyle configurado y PMD para seguir estas convenciones de codificación, adicionalmente proporcionó un espacio de trabajo predeterminado para Eclipse que tenía la configuración correcta que se ajusta a las configuraciones definidas de Checkstyle y PMD.
  3. Añadimos tres capítulos a nuestras convenciones de codificación que explicaban qué configuración de Checkstyle, PMD y Eclipse cumplía con qué parte de la guía de estilo, para que cada arquitecto pudiera modificar la guía de estilo y las configuraciones de Checkstyle, PMD y Eclipse.
  4. Desarrollamos pequeños complementos para que al instalar Checkstyle y PMD junto con nuestros complementos, nuestra convención de codificación definida por Checkstyle y PMD fuera la predeterminada y fácil de seleccionar.

Creemos que ayuda mucho no solo escribirlo, sino integrarlo en el entorno de desarrollo. Por otro lado, hacemos eso solo para Eclpise, porque es demasiado para hacer si quieres eso para cada IDE en la tierra.

Cuestiones relacionadas