directrices para mejorar su código

Question

¿Qué pautas sigues para mejorar la calidad general de su código? Muchas personas tienen reglas sobre cómo escribir código C++ que (supuestamente) hacen que sea más difícil cometer errores. He visto personas insistir que cada instrucción if es seguida por un bloque de llaves ({...}).

Me interesan las pautas que siguen otras personas y las razones que las respaldan. También me interesan las pautas que piensas que son basura, pero que son comunes. ¿Alguien puede sugerir algunos?

Para rodar la pelota, voy a mencionar unos pocos para comenzar con:

• Siempre use los frenos después de cada sentencia if/else (mencionado anteriormente). La razón detrás de esto es que no siempre es fácil saber si una sola instrucción es en realidad una declaración, o una macro preprocesador que se expande a más de una sentencia, por lo que este código se rompería:

 
    // top of file: 
    #define statement doSomething(); doSomethingElse 

    // in implementation: 
    if (somecondition) 
     doSomething(); 

pero si usa llaves, entonces funcionará como se espera.

• Utilice las macros del preprocesador SOLAMENTE para la compilación condicional. las macros de preprocesador pueden causar todo tipo de infierno, ya que no permiten las reglas de exploración de C++. Me he encallado muchas veces debido a las macros del preprocesador con nombres comunes en los archivos de encabezado. ¡Si no tienes cuidado, puedes causar todo tipo de estragos!

Ahora a usted.

Answer 1

Algunos de mis favoritos personales:

Esforzarse para escribir código que es const correct. Alistarás el compilador para que te ayude a eliminarlo, pero a veces son bugs muy dolorosos. El código también contar una historia de lo que tenía en mente en el momento en que lo escribió - valiosa para los recién llegados o personal de mantenimiento una vez que has ido.

salir del negocio de gestión de memoria. Aprenda a usar punteros inteligentes: std::auto_ptr, std::tr1::shared_ptr (o boost::shared_ptr) y boost::scoped_ptr. Conozca las diferencias entre ellos y cuándo usar uno frente a otro.

Probablemente va a utilizar la Biblioteca de plantillas estándar. Lea el Josuttis book. No se detenga después de los primeros capítulos en contenedores pensando que conoce el STL. Presiona a lo bueno: algoritmos y objetos de función.

Answer 2

asegurarse de sangría correctamente

Answer 3

• Uso y aplicar un estilo de codificación común y orientaciones. Justificación: Cada desarrollador en el equipo o en la empresa es capaz de leer el código sin distracciones que pueden ocurrir debido a diferentes estilos abrazadera o similar.
• Realice una reconstrucción completa de toda su base de origen (es decir, realice compilaciones o compilaciones diarias después de cada registro) e informe cualquier error. Justificación: La fuente es casi siempre en un estado utilizable, y los problemas se detectó poco después de que se "apliquen", donde la resolución de problemas es barato.

Answer 4

En caso de declaraciones ponen la constante de la izquierda, es decir

if(12 == var) 

no

if(var == 12) 

Beacause si se olvida de escribir una asignación '=', entonces se vuelve. En la versión superior, el compilador dice que esto no es posible, en el último se ejecuta y el if es siempre verdadero.

Uso llaves para si siempre que no estén en la misma línea.

if(a == b) something(); 
if(b == d) 
{ 
    bigLongStringOfStuffThatWontFitOnASingleLineNeatly(); 
} 

Las llaves de apertura y cierre siempre tienen sus propias líneas. Pero eso es, por supuesto, una convención personal.

Answer 5

En la misma línea que pueden encontrar algunas sugerencias útiles aquí: How do you make wrong code look wrong? What patterns do you use to avoid semantic errors?

Answer 6

• Use las pestañas para hendiduras, pero alinear los datos con espacios Esto significa que la gente puede decidir cuánto guión cambiando el tamaño de la pestaña, sino también que las cosas permanezcan alineados (por ejemplo, es posible que desee todos los '=' en una línea vertical cuando los valores asignar a un struct)

• Allways utilizan constantes o funciones en línea en lugar de macros donde Posible

• Nunca use 'using' en los archivos de encabezado, porque todo lo que incluye ese heafer también se verá afectado, incluso si la persona que incluye su encabezado no quiere todos los std (por ejemplo) en su espacio de nombres global.

• Si algo es más largo que unos 80 columes, dividirla en varias líneas por ejemplo

  if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) && 
      BigVaribleIsValid(SomeVeryLongVaribleName)) 
  { 
      DoSomething(); 
  } 
  

• Sólo los operadores de sobrecarga para hacer que hagan lo que el usuario espera, por ejemplo, la sobrecarga de los signos + y - los operadores para una 2dVector está bien

• Siempre comente su código, incluso si es solo para decir lo que está haciendo el próximo bloque (por ejemplo, "eliminar todas las texturas que no son necesarias para este nivel"). Es posible que alguien necesite trabajar más tarde, posiblemente después de que se haya ido y no quiera encontrar miles de líneas de código sin comentarios que indiquen qué hace qué.

Answer 7

1. Borrar código innecesario.

Eso es todo.

Answer 8

1. Use un formato uniforme.
2. Cuando trabaje en código heredado, emplee el estilo existente de formateo, esp. estilo de refuerzo.
3. obtener una copia del libro de Scott Meyer efectiva C++
4. Obtener una copia del Código de libro de Steve MConnell completa.

Answer 9

Solo comenten cuando solo es necesario explicar lo que está haciendo el código, donde leer el código no podría decir lo mismo.

No anotes el código que no estás utilizando más. Si desea recuperar el código anterior, use su sistema de control de origen. Comentar el código simplemente hace que las cosas se vean desordenadas, y hace que sus comentarios que realmente son importantes se desvanezcan en el desorden de fondo del código comentado.

Answer 10

1. configuración convención de codificación y hacer que todos los involucrados siguen la convención (que no le gustaría leer el código que hacen que deba averiguar dónde está la siguiente sentencia/expresión, ya que no se aplica sangría correctamente)
2. constantemente Refactorizando código (obtenga una copia de Refactoring, por Martin Fowler, los pros y los contras se detallan en el libro)
3. escriba el código ligeramente acoplado (evite escribir comentarios escribiendo código explicativo, el código débilmente acoplado tiende a ser más fácil de administrar/adaptar para cambiar)
4. si es posible, prueba tu código de la unidad (o si eres lo suficientemente macho, TDD.)
5. release early
6. evitar la optimización prematura (perfiles ayuda a optimizar)

Answer 11

encender todas las alarmas que puede interponerse en su compilador (gcc: -Wall es un buen comienzo, pero no incluye todo, así que revise los documentos) y haga que se conviertan en errores, por lo que debe corregirlos (gcc: -Werror).

Answer 12

Hmm - Probablemente debería haber sido un poco más específico.

No estoy buscando tanto asesoramiento para mí mismo - Estoy escribiendo una herramienta de análisis de código estático (las ofertas comerciales actuales simplemente no son lo suficientemente buenas para lo que quiero), y estoy buscando ideas para complementos para resaltar posibles errores en el código.

Varias personas han mencionado cosas como const correctness y el uso de punteros inteligentes: ese es el tipo de cosas que creo que puedo verificar. La comprobación de indentación y comentarios es un poco más difícil de hacer (desde un punto de vista de programación de todos modos).

Answer 13

También hay un buen C++ Style Guide utilizado internamente por Google, que incluye la mayoría de las reglas mencionadas aquí.

Answer 14

La guía de estilo de Google, mencionada en una de estas respuestas, es bastante sólida. Hay algunas cosas inútiles, pero es más bueno que malo.

Sutter y Alexandrescu escribieron un libro decente sobre este tema, llamado C++ Coding Standards.

He aquí algunos consejos generales de lil me ole:

1. Su sangría horquillado y el estilo son a la vez malo. Lo mismo ocurre con los demás. Así que sigue los estándares del proyecto para esto. Trate su orgullo y configure su editor para que todo sea lo más constante posible con el resto de la base de código. Es realmente molesto tener que leer el código sangrado de forma irregular. Dicho esto, el horquillado y la sangría no tienen nada que ver con "mejorar tu código". Se trata más de mejorar tu habilidad para trabajar con otros.

2. Comentario bien. Esto es extremadamente subjetivo, pero en general siempre es bueno escribir comentarios sobre por qué el código funciona de la forma en que lo hace, en lugar de explicar lo que hace.Por supuesto, para código complejo también es bueno para los programadores que pueden no estar familiarizados con el algoritmo o el código tener una idea de lo que está haciendo también. Los enlaces a las descripciones de los algoritmos empleados son muy bienvenidos.

3. Exprese la lógica de la manera más directa posible. Irónicamente, las sugerencias como "poner constantes en el lado izquierdo de las comparaciones" han salido mal aquí, creo. Son muy populares, pero para los que hablan inglés, a menudo rompen el flujo lógico del programa con los que leen. Si no puedes confiar en ti mismo (o en tu compilador) para escribir la igualdad se compara correctamente, entonces usa trucos como este. Pero sacrificas la claridad cuando lo haces. También caer dentro de esta categoría son cosas como ... "¿Mi lógica tiene 3 niveles de sangrado? ¿Podría ser más simple?" e implementar un código similar en funciones. Tal vez incluso dividiendo funciones. Se necesita experiencia para escribir código que exprese elegantemente la lógica subyacente, pero vale la pena trabajar en ello.

Esas fueron bastante generales. Para consejos específicos, no puedo hacer un trabajo mucho mejor que Sutter y Alexandrescu.

Answer 15

Donde pueda, use el preincremento en lugar del incremento posterior.

Answer 16

Comience a escribir muchos comentarios, pero use eso como una oportunidad para refactorizar el código para que se pueda explicar por sí mismo.

es decir:

for(int i=0; i<=arr.length; i++) { 
    arr[i].conf() //confirm that every username doesn't contain invalid characters 
} 

debería haber sido algo más parecido a

for(int i=0; i<=activeusers.length; i++) { 
    activeusers[i].UsernameStripInvalidChars() 
} 

Answer 17

utilizo PC-pelusa en mi C++ proyectos y, especialmente, al igual que la forma en que hace referencia a las publicaciones existentes, tales como las directrices MISRA o "Effective C++" de Scott Meyers y "C++ más efectivo". Incluso si planea escribir justificaciones muy detalladas para cada regla que verifique su herramienta de análisis estático, es una buena idea señalar las publicaciones establecidas en las que confía su usuario.

Answer 18

Aquí es la pieza más importante del consejo que me dieron por el gurú de C++, y eso me ayudó en algunas ocasiones críticos para encontrar errores en mi código:

• Utilizar métodos const cuando un método es no se supone para modificar el objeto.
• Utilice referencias y punteros en los parámetros cuando el objeto es no se supone para modificar el objeto.

Con estas 2 reglas, el compilador le dirá de forma gratuita en qué parte de su código la lógica es defectuosa.

Answer 19

Los indicadores inteligentes tienen una buena manera de indicar la propiedad con mucha claridad. Si usted es una clase o una función:

• si obtiene un puntero prima, que no es dueño de nada. Se le permite usar la punta, cortesía de su interlocutor, quien garantiza que la punta permanecerá viva más tiempo que usted.
• si obtienes un weak_ptr, no eres dueño de la punta y, además, la punta puede desaparecer en cualquier momento.
• si le da una shared_ptr, usted es dueño del objeto junto con otros, por lo que no hay que preocuparse. Menos estrés, pero también menos control.
• si obtiene un auto_ptr, usted es el único propietario del objeto. Es tuyo, eres el rey. Usted tiene el poder de destruir ese objeto, o dárselo a otra persona (perdiendo así la propiedad).

Creo que el caso de auto_ptr es particularmente fuerte: en un diseño, si veo un auto_ptr, inmediatamente sé que ese objeto va a "vagar" de una parte del sistema a la otra.

Esto es al menos la lógica que uso en mi proyecto favorito. No estoy seguro de cuántas variaciones puede haber sobre el tema, pero hasta ahora este conjunto de reglas me ha sido útil.

Answer 20

Además, para algunas buenas técnicas es posible que siga Google's blog "Testing on the Toilet".

Answer 21

Mira que seis meses más tarde

Answer 22

C# Coding Standards and Naming Conventions

A continuación se presentan nuestros estándares de codificación C#, las convenciones de nombres, y las mejores prácticas. Úselos en sus propios proyectos y/o ajústelos a sus propias necesidades.

Convenciones de nomenclatura y Estilo

hacen uso PascalCasing de nombres de clases y nombres de método.

Por qué: compatible con Microsoft .NET Framework y fácil de leer.

do use camelCasing para argumentos de método y variables locales.

qué: consistente con el Microsoft .NET Framework y fácil de leer.

no lo hacen: uso notación húngara o cualquier otro tipo de identificación en los identificadores

qué: consistente con el Microsoft .NET Framework y Visual Studio hace que la determinación de tipos muy fácil (a través de la información de herramientas). En general, desea evitar los indicadores de tipo en cualquier identificador.

No uso Screaming Tapas para constantes o variables de sólo lectura

Read more on "C# Coding Standards and Naming Conventions" with example here