Pautas para mejorar tu código

Question

¿Qué pautas sigues para mejorar la calidad general de tu código?Mucha gente tiene reglas sobre cómo escribir código C++ que (supuestamente) hacen que sea más difícil cometer errores.he visto gente insistir que cada if La declaración va seguida de un bloque de llaves ({...}).

Me interesan las pautas que siguen otras personas y las razones detrás de ellas.También me interesan las pautas que usted cree que son basura, pero que se mantienen comúnmente.¿Alguien puede sugerir algunos?

Para empezar, mencionaré algunos para empezar:

• Utilice siempre aparatos ortopédicos después de cada if / else declaración (mencionada anteriormente).La razón detrás de esto es que no siempre es fácil saber si una sola declaración es en realidad una sola declaración o una macro de preprocesador que se expande a más de una declaración, 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, funcionará como se esperaba.

• Utilice macros de preprocesador SÓLO para compilación condicional.Las macros de preprocesador pueden causar todo tipo de problemas, ya que no permiten reglas de alcance de C++.Me he quedado encallado muchas veces debido a macros de preprocesador con nombres comunes en los archivos de encabezado.¡Si no tienes cuidado puedes causar todo tipo de estragos!

Ahora te toca a ti.

Answer 1

Algunos de mis favoritos personales:

Esfuércese por escribir código que sea constante correcta.Utilizará el compilador para ayudar a eliminar errores fáciles de corregir pero a veces dolorosos.Su código también contará una historia de lo que tenía en mente en el momento en que lo escribió, algo valioso para los recién llegados o los encargados del mantenimiento una vez que se haya ido.

Salga del negocio de la gestión de la memoria.Aprenda a utilizar 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 vs.otro.

Probablemente utilizará la biblioteca de plantillas estándar.Leer el libro de josutti.No se detenga después de los primeros capítulos sobre contenedores pensando que conoce el STL.Avance hacia las cosas buenas:Algoritmos y objetos funcionales.

Answer 2

1. Eliminar código innecesario.

Eso es todo.

Answer 3

• Utilice y aplique pautas y estilos de codificación comunes. Razón fundamental: Cada desarrollador del equipo o de la empresa puede leer el código sin distracciones que puedan ocurrir debido a diferentes estilos de llaves o similares.
• Realice periódicamente una reconstrucción completa de toda su base fuente (es decir,haga compilaciones diarias o compilaciones después de cada registro) e informe cualquier error. Razón fundamental: La fuente casi siempre está en un estado utilizable y los problemas se detectan poco después de su "implementación", donde la resolución de problemas es barata.

Answer 4

Active todas las advertencias que pueda soportar en su compilador (gcc: -Wall es un buen comienzo, pero no incluye todo, así que consulte los documentos) y cometa errores para que tenga que corregirlos (gcc: -Werror).

Answer 5

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

Sutter y Alexandrescu escribieron un libro decente sobre este tema, llamado Estándares de codificación C++.

Aquí hay algunos consejos generales de mi pequeño:

1. Tanto el estilo de sangría como el de corchetes son incorrectos.También lo son los de todos los demás.Así que siga los estándares del proyecto para esto.Trágate tu orgullo y configura tu editor para que todo sea lo más consistente posible con el resto del código base.Es realmente molesto tener que leer código con sangría inconsistente.Dicho esto, los corchetes y la sangría no tienen nada que ver con "mejorar su código". Se trata más de mejorar su capacidad para trabajar con otros.

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

3. Expresar la lógica de la manera más directa posible.Irónicamente, creo que sugerencias como "poner constantes en el lado izquierdo de las comparaciones" han salido mal aquí.Son muy populares, pero para los angloparlantes, a menudo rompen el flujo lógico del programa para quienes leen.Si no puede confiar en usted mismo (o en su compilador) para escribir comparaciones de igualdad correctamente, utilice trucos como este.Pero estás sacrificando claridad cuando lo haces.También entran en esta categoría cosas como..."¿Mi lógica tiene 3 niveles de sangría?¿Podría ser más simple?" y convertir código similar en funciones.Quizás incluso dividir funciones.Se necesita experiencia para escribir código que exprese elegantemente la lógica subyacente, pero vale la pena trabajar en ello.

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

Answer 6

En las declaraciones if, coloque la constante a la izquierda, es decir

if( 12 == var )

no

if( var == 12 )

Porque si no escribes un '=" entonces se convierte en una tarea.En la versión superior, el compilador dice que esto no es posible, en la última se ejecuta y el if siempre es cierto.

Utilizo llaves para los if cuando 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, por supuesto, es una convención personal.

Answer 7

Comente solo cuando sea necesario explicar qué está haciendo el código, cuando leer el código no pueda decirle lo mismo.

No comentes el código que ya no estás usando.Si desea recuperar el código antiguo, utilice su sistema de control de fuente.Comentar el código simplemente hace que las cosas parezcan desordenadas y hace que los comentarios que en realidad son importantes se desvanezcan en el fondo del código comentado.

Answer 8

1. Utilice un formato coherente.
2. Cuando trabaje en código heredado, emplee el estilo de formato existente, especialmente.estilo corsé.
3. Obtenga una copia del libro de Scott Meyer Effective C++
4. Obtenga una copia del libro Code Complete de Steve MConnell.

Answer 9

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

Answer 10

Empiece a escribir muchos comentarios, pero utilícelo como una oportunidad para refactorizar el código para que se explique 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

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

Answer 11

• Use pestañas para las hendiduras, pero alinee los datos con los espacios Esto significa que las personas pueden decidir cuánto sangrar al cambiar el tamaño de la pestaña, pero también que las cosas permanecen alineadas (por ejemplo, es posible que desee todo el '=' en una línea vertical cuando asigne valores a un estructura)

• Utilice siempre constantes o funciones en línea en lugar de macros cuando sea posible

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

• Si algo tiene más de 80 columnas, divídalo en varias líneas, por ejemplo

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

• Solo sobrecargar los operadores para que hagan lo que el usuario espera, por ejemplo, sobrecargar los operadores + y - para un 2dVector está bien.

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

Answer 12

1. configure la convención de codificación y haga que todos los involucrados sigan la convención (no querrá leer código que requiera que averigüe dónde está la siguiente declaración/expresión porque no tiene sangría adecuada)
2. refactorizar constantemente su código (obtenga una copia de Refactoring, de Martin Fowler, los pros y los contras se detallan en el libro)
3. escribir código débilmente acoplado (evite escribir comentarios escribiendo código que se explique por sí mismo, el código débilmente acoplado tiende a ser más fácil de administrar/adaptar al cambio)
4. si es posible, realice una prueba unitaria de su código (o si es lo suficientemente macho, TDD).
5. Libertad anticipada, la liberación a menudo
6. Evite la optimización prematura (la creación de perfiles ayuda a optimizar)

Answer 13

De manera similar, puede encontrar algunas sugerencias útiles aquí: ¿Cómo se hace para que un código incorrecto parezca incorrecto?¿Qué patrones utilizas para evitar errores semánticos?

Answer 14

Siempre que pueda, utilice el incremento previo en lugar del incremento posterior.

Answer 15

Utilizo PC-Lint en mis proyectos de C++ y me gusta especialmente cómo hace referencia a publicaciones existentes como las pautas de MISRA o "Effective C++" y "More Effective C++" de Scott Meyers.Incluso si planea escribir justificaciones muy detalladas para cada regla que verifica su herramienta de análisis estático, es una buena idea señalar publicaciones establecidas en las que su usuario confíe.

Answer 16

Este es el consejo más importante que me dio un gurú de C++ y que me ayudó en algunas ocasiones críticas a encontrar errores en mi código:

• Utilice métodos constantes cuando un método sea no se supone para modificar el objeto.
• Utilice referencias constantes y punteros en los parámetros cuando el objeto sea 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 17

Además, para conocer algunas buenas técnicas que puedes seguir Blog de Google "Pruebas en el baño".

Answer 18

Míralo seis meses después.

Answer 19

asegúrese de sangrar correctamente

Answer 20

Hmm, probablemente debería haber sido un poco más específico.

No busco tanto consejos para mí: 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 de complementos para resaltar posibles errores en el código.

Varias personas han mencionado cosas como la corrección constante y el uso de punteros inteligentes; ese es el tipo de pensamiento que puedo verificar.Verificar sangrías y comentarios es un poco más difícil de hacer (al menos desde el punto de vista de la programación).

Answer 21

Los punteros inteligentes tienen una buena forma de indicar la propiedad con mucha claridad.Si eres una clase o una función:

• si obtienes un puntero crudo, no posees nada.Puedes usar la punta, cortesía de quien llama, quien garantiza que la punta permanecerá viva más tiempo que tú.
• si obtienes un débil_ptr, no eres dueño de la punta y, además, la punta puede desaparecer en cualquier momento.
• si obtienes un ptr_compartido, eres propietario del objeto junto con otros, por lo que no debes preocuparte.Menos estrés, pero también menos control.
• si obtienes un auto_ptr, eres el único propietario del objeto.Es tuyo, eres el rey.Tienes el poder de destruir ese objeto o dárselo a otra persona (perdiendo así la propiedad).

Encuentro el caso de auto_ptr particularmente sólido: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.

Esta 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 de gran utilidad.