it-swarm-es.com

¿Qué partes de su estándar de codificación contribuyen al código de calidad?

En respuesta a Esta pregunta , pregunto: ¿Cuáles son las mejores partes de su estándar de codificación?

¿Cuáles son las mejores prácticas que ayudan con la calidad del código, la confiabilidad, la facilidad de mantenimiento, la legibilidad, etc.

Incluya el idioma, el elemento del estándar y la razón por la que mejora su código.

31
AShelly

Todos los idiomas: escriba código legible en lugar de comentarios

  • Un comentario seguido de un bloque de código puede ser reemplazado por un método que establece la intención tan bien como el comentario, y hace que el código sea más modular y reutilizable también.
  • Hace que la refactorización suceda con más frecuencia.
  • Nos ayuda a escribir simple, legiblecódigo limpio . Es un placer trabajar con un código legible.
  • Tiende a hacer que los métodos sean cortos y dulces.
  • Evita que los comentarios no estén sincronizados con el código
  • Te reta a reescribir el código comentado que es difícil de entender.

Compara esto:

public void update() {
  // Fetch the data from somewhere
  lots of lines of;
     code;
     for;
       fetching;
     data;
  from somewhere;
  // Sort the data
  more lines of;
      code;
         which sorts;
         stuff;
      around;
  a bit and then;
  // Update the database
  lines of code;
      which uses;
         some lib;
         to update;
            using iteration;
            and logic; 
      the database;
  done;
}

Con esta versión donde los comentarios se reemplazan con llamadas a funciones:

public void update() {
    data = fetchData();
    sorted = sortResults(data);
    updateDatabase(sorted);
}
23
Martin Wickman

Solo se debe poner una clase pública en cada archivo, no más.

12
Maniero

Cualquier idioma:

so adecuado y consistente de espacios en blanco tanto vertical como horizontal, enormemente mejora la capacidad del código para ser rápidamente descremado también como se lee a un ritmo normal. No voy a discutir sobre pestañas versus espacios, siempre que su uso sea consistente, pero la sangría adecuada y el uso juicioso de líneas y espacios en blanco alrededor de los operadores son absolutamente necesarios.

Relacionado: mantener las longitudes de línea a un límite razonable, como 80 columnas, tiene beneficios demostrables: no hay envolturas extrañas en las consolas, no es necesario desplazarse y la capacidad de ver múltiples archivos uno al lado del otro en un monitor ancho, sin mencionar que tiende a ayudar a fomentar la refactorización de código profundamente anidado y expresiones de ejecución.

9
Jon Purdy

C #: Diferentes estilos de nombres para diferentes tipos de nombres.

Por ejemplo:

public class ClassNamesArePascalCase{
    public int FieldsArePascalCase;
    private int _privateFieldsAreUnderscoredCamelCase
    public const int CONSTANTS_ARE_CAPITAL = 3;

    public void MethodNamesArePascalCase( string parametersAreCamel ){
        int localVariablesAreCamel;
    }
}

No importa mucho qué estándares utilice para qué tipos de nombre, siempre que sea coherente entre ese tipo (por ejemplo, todas las constantes son mayúsculas), coherentes dentro del proyecto y diferentes entre sí. El beneficio aquí es que puedo decir de un vistazo que _algunosVar es un campo privado sin tener que buscarlo.

7
Fishtoaster

C : Las 'funciones' de la macro del preprocesador deben estar en mayúsculas

Ejemplo: #define CUBE(x) ((x)*(x)*(x))

Motivo: al escanear el código, las macros se destacan de las funciones normales y le alertan de que puede haber efectos secundarios que una llamada de función normal nunca tendría, como cambiar el valor del argumento "input" o hacer que se evalúe 3 ​​veces.

6
AShelly

Nunca use la notación húngara. En los idiomas de tipos estáticos no es necesario, y en los idiomas de tipo dinámico casi siempre es dañino. Además, la notación húngara es el arma nuclear táctica de las técnicas de ofuscación del código fuente .

5
pillmuncher

En Java.

  • Invoque el formateador del código fuente de Eclipse automáticamente cada vez que se guarde un archivo.

Esto significa que los cambios en el código fuente se registran en la primera confirmación posterior, en lugar de un tiempo posterior cuando se realiza un reformateo. Esto es bueno cuando se realizan investigaciones de "cuándo se cambió esto".

5
user1249

[~ # ~] consistencia [~ # ~]

No me molestan las convenciones de nomenclatura o codificación en particular (aunque, obviamente, tengo preferencias) siempre que la base de código a la que se apliquen use esas convenciones de manera consistente.

He estado pasando Código limpio últimamente, y encuentro que me ha ayudado bastante (aunque no estoy de acuerdo/uso todo).

3
Steven Evers

C #: Usar el método de extracción en lugar de comentarios

Si sentimos que necesitamos agregar un comentario a un bloque de código para explicar lo que está haciendo, en su lugar extraeríamos ese código en un nuevo método con un nombre descriptivo.

Esto hace que el código sea más legible y modular, y reduce la cantidad de comentarios (desactualizados) que flotan.

3
David Anderson

Formateo - ¡especialmente sangría! Estoy usando Delphi y lo primero que debo hacer cuando obtengo código no formateado para mi uso lo reformateo. El formateador incorporado en Delphi sirve como una de las características más utilizadas en estos casos.

3
Uwe Raabe

SQL

Utilizamos una convención de nomenclatura para nuestros elementos de base de datos.

  • tblTableNames
  • viewViewName
  • spAdminProcedureName
  • spProcedureName

A veces creamos un widget para un cliente y 3 meses después revendemos ese widget a otro cliente. Eventualmente surgieron conflictos de nombres y tuvimos que volver a codificar un widget.

Por ejemplo:
widget de comunicado de prensa

  • tblContent
  • tblCategories
  • tblImages

widget de la galería de fotos

  • tblPhotos
  • tblCategories

Si el Cliente-A ya tenía el widget de comunicado de prensa y ahora quería el widget de Galería de fotos, tuvimos un conflicto de nombres con tblCategories. No podíamos simplemente escribir los elementos de la Galería de fotos y ejecutarlos contra la base de datos de la Compañía-A. Argh!

Entonces, comenzamos a agregar referencias "widget" a nuestros elementos SQL:

  • tblPG_Photos
  • tblPG_Categories
  • tblPR_Content
  • tblPR_Categories
  • tblPR_Images
  • spPG_Proc1
  • spPG_Proc2
  • spPG_Proc3
  • spPR_Proc1
  • spPR_Proc2
  • spPR_Proc3

Esto mantuvo las cosas bien agrupadas y nos ayudó a ser más rentables a largo plazo.

C # y Java:

  • Asegurarse de que el registro de las secciones críticas esté correctamente definido (log4 *).
  • Mantenga los métodos y las clases pequeños (responsabilidad única).
  • TDD o pruebas de unidad de escritura para secciones importantes de lógica de negocios (jUnit o nUnit).
1
Watson

Para herencia C++. Señalando eso,

  • Herencia múltiple: Muy rara vez la herencia de implementación múltiple es realmente útil.

Por otras cosas.

  • Macros de preprocesador: Tenga mucho cuidado con las macros. Prefiere funciones en línea, enumeraciones y variables constantes a las macros.
  • Smart Pointers: Si realmente necesita semántica de puntero, scoped_ptr es excelente. Solo debe usar std :: tr1 :: shared_ptr en condiciones muy específicas, como cuando los contenedores STL deben contener objetos. Nunca debe usar auto_ptr.
1
grokus

En Python, use solo la biblioteca estándar, y si no puede evitar usar otra biblioteca, explique por qué en algún lugar. Algún día, tal vez sea necesario reemplazar la lib y sería bueno saber por dónde empezar.

Además, que sea muy muy simple.

0

Escribí sobre esto en mi blog el otro día.

Convenciones y estándares de codificación de C #

http://www.codehustle.com/2011/06/c-coding-conventions-and-standards.html

Creo que, en lo que respecta a las convenciones de codificación, lo principal que contribuye a la confiabilidad, facilidad de mantenimiento y legibilidad del código son las convenciones de nombres. El resto de las cosas es bastante estándar.

No hay una forma "correcta" o "incorrecta" con las convenciones de nomenclatura. La clave es la consistencia. Por ejemplo, siempre uso camelCasing para parámetros y variables locales, uso camelCasing con un guión bajo para los miembros de campo privados/protegidos, y uso PascalCasing para nombres de clase, propiedades, eventos, funciones, etc.

Por lo general, evito la notación húngara en aras de la legibilidad, pero creo que en algunos escenarios es útil (generalmente uso la notación húngara para los tipos de GUI).

Un efecto secundario de apegarse a las convenciones es que es fácil hacer un seguimiento de qué tipo de identificador está mirando al leer el código. Por ejemplo, siempre puedo confiar en el hecho de que las propiedades utilizan PascalCasing mientras que las variables locales no, lo que me evita tener que escanear y encontrar la definición de un identificador al leer el código.

Hacer que su equipo siga las mismas convenciones y estándares de codificación puede ayudar a que su software sea más legible y más uniforme al mantener las cosas consistentes y limpias. Esto facilita el mantenimiento al permitir que los miembros de su equipo puedan leer y comprender el código escrito por compañeros de trabajo más rápidamente sin tener que ejecutar mentalmente un filtro de fondo para interpretar las diferencias de diseño y estilo, etc. También fomenta las mejores prácticas y puede contribuir a manteniendo sus API consistentes también.

Si su código es limpio, consistente y fácil de leer, se vuelve más fácil de mantener y menos propenso a errores.

0
John Connelly

Método de nombre único, no importa en el idioma. Por ejemplo ... G = Global, L = Local, P = Parámetro. Ahora, cuando tiene una variable como G_strFoo, sé que su definición se puede ubicar en mi archivo global. Ayuda a mantenerse al día con todas las variables en mis programas.

0
Jeremy