¿Qué es una buena convención de nombres para vars, métodos, etc. en C++?

Question

Vengo del mundo de Objective-C y Cocoa, donde hay muchas convenciones y mucha gente dirá que hace que tu código sea hermoso. Ahora la programación en C++ no puedo encontrar un buen documento como este para C++.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

estándar de C++ no tiene probablemente algo así como el anterior pero espero que pueda pegarse a algún otro SDK o API (como Microsoft (?), Etc) convenciones.

Espero que pueda proporcionarme algunos enlaces.

Answer 1

Haga lo que quiera siempre que sea mínimo, consistente y doesn't break any rules.

Personalmente, encuentro que el estilo Boost es más fácil; coincide con la biblioteca estándar (dando un aspecto uniforme al código) y es simple.Yo personalmente virar en m y p prefijos a los miembros y los parámetros, respectivamente, dando:

#ifndef NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP 
#define NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP 

#include <boost/headers/go/first> 
#include <boost/in_alphabetical/order> 
#include <then_standard_headers> 
#include <in_alphabetical_order> 

#include "then/any/detail/headers" 
#include "in/alphabetical/order" 
#include "then/any/remaining/headers/in" 
// (you'll never guess) 
#include "alphabetical/order/duh" 

#define NAMESPACE_NAMES_THEN_MACRO_NAME(pMacroNames) ARE_ALL_CAPS 

namespace lowercase_identifers 
{ 
    class separated_by_underscores 
    { 
    public: 
     void because_underscores_are() const 
     { 
      volatile int mostLikeSpaces = 0; // but local names are condensed 

      while (!mostLikeSpaces) 
       single_statements(); // don't need braces 

      for (size_t i = 0; i < 100; ++i) 
      { 
       but_multiple(i); 
       statements_do(); 
      }    
     } 

     const complex_type& value() const 
     { 
      return mValue; // no conflict with value here 
     } 

     void value(const complex_type& pValue) 
     { 
      mValue = pValue ; // or here 
     } 

    protected: 
     // the more public it is, the more important it is, 
     // so order: public on top, then protected then private 

     template <typename Template, typename Parameters> 
     void are_upper_camel_case() 
     { 
      // gman was here     
     } 

    private: 
     complex_type mValue; 
    }; 
} 

#endif 

Eso. (Y como he dicho en los comentarios, qué no aprobará la guía de estilo para Google su código, a menos que sea por algo tan insignificante como la convención de nombres.)

Answer 2

Mientras que muchas personas sugieren variantes más 0 menos Hungarian notation (scary!), Para dar nombre a las sugerencias, sugiero que eche un vistazo a Google C++ Coding Guidelines. Esta bien puede no ser la convención de nombres más popular, pero al menos es bastante completa. Además de las convenciones de nombres de sonido, hay algunas pautas útiles allí, sin embargo, gran parte de lo que se debe tomar con un grano de sal (prohibición de excepción, por ejemplo, y la tendencia a mantenerse alejado del estilo moderno de codificación C++).

Aunque personalmente me gusta el estilo de convención de baja tecnología extrema de STL y Boost;).

Answer 3

no tan concisa como el enlace que ya ha proporcionado: pero el siguiente capítulo 14 - 24 de mayo ayudar :) jeje

ref: http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586/ref=sr_1_1?ie=UTF8&s=books&qid=1284443869&sr=8-1-catcorr

Answer 4

Para abordar la cuestión más amplia de guías de estilo Sugiero elegir uno y apegándose a eso
El Google style guide es muy detallado/completo, por lo que es una buena opción.

Una convención común sólo para nombrar es:

• camelCase para todos los nombres (excepto constantes).
• Comenzando con un capital si se trata de una clase.
• Minúscula si no es así.
• Constantes en ALL_CAPS con trabajos de separación de subrayado.
• Las funciones se pueden escribir igual que las variables, camelCase (se puede decir que es una función porque requiere () después).
• Y las variables miembro con un prefijo m y por lo tanto se escribirían mCamelCase.

Depende realmente de usted o, alternativamente, las personas para las que trabaja o la universidad en la que estudia.

Para una vista detallada de una variedad de guías de estilo/fundamentos detrás de ellas, consulte Pragmatic Programmer por Andrew Hunt y David Thomas.

Answer 5

Realmente no importa. Solo asegúrate de nombrar tus variables y funciones descriptivamente. También sé consistente.

Nowt peor que ver código como este:

int anInt;     // Great name for a variable there ... 
int myVar = Func(anInt); // And on this line a great name for a function and myVar 
          // lacks the consistency already, poorly, laid out! 

Edit: Como ha señalado mi comentarista en que la consistencia tiene que ser mantenida a través de todo un equipo. Como tal, no importa qué método elija, siempre que se mantenga esa coherencia. Sin embargo, no existe un método correcto o incorrecto. Cada equipo en el que he trabajado ha tenido diferentes ideas y me he adaptado a ellas.

Answer 6

Probablemente haya tantas convenciones de nomenclatura como personas, el debate es interminable (y estéril) sobre qué estilo de refuerzos usar y demás.

Así que voy a tener 2 consejos:

• sean consistentes dentro de un proyecto
• no utilizan identificadores reservados (cualquier cosa con dos guiones bajos o que comienzan con un guión bajo seguido de una letra mayúscula)

El resto depende de usted.

Answer 7

Hay muchos símbolos/convenciones diferentes que las personas usan al codificar C++. Por ejemplo, algunas personas prefieren separar palabras usando mayúsculas (myVar o MyVar), o usando guiones bajos (my_var). Normalmente, las variables que usan guiones bajos están en minúsculas (según mi experiencia).
También hay un estilo de codificación llamado húngaro, que creo que es usado por microsoft. Personalmente, creo que es una pérdida de tiempo, pero puede resultar útil. Este es el nombre de las variables que reciben prefijos cortos como i o f para indicar el tipo de variables. Por ejemplo: int iVarname, char * strVarname.

Se acepta que finalice un nombre de estructura/clase con _t, para diferenciarlo de un nombre de variable. Ej .:

class cat_t { 
    ... 
}; 

cat_t myCat; 

Está generalmente aceptado también añadir un afijo para indicar punteros, como pVariable o variable_p.

En total, realmente no hay una sola estándar, pero muchas. Las elecciones que haga para nombrar sus variables no son importantes, siempre que sea comprensible y, sobre todo, coherente. Consistencia, consistencia, consistencia! (¡intente escribir ese tres veces!)

Y si todo lo demás falla, escríbalo.

Answer 8

seguimos las directrices que figuran en esta página: C++ Programming Style Guidelines

---

También recomiendo que leas The Elements of C++ Style by Misfeldt et al, que es bastante un excelente libro sobre este tema.

Answer 9

De hecho, a menudo uso el estilo de Java: PascalCase para nombres de tipos, camelCase para funciones y variables, CAPITAL_WORDS para macros de preprocesador. Prefiero eso sobre las convenciones de Boost/STL porque no es necesario que los tipos de sufijo con _type. P.ej.

Size size(); 

en lugar de

size_type size(); // I don't like suffixes 

Esto tiene la ventaja adicional de que el formateador de código Stackoverflow reconoce Size como un nombre de tipo ;-)

Answer 10

consistencia y facilidad de lectura (código de auto-documentado) son importantes . algunas pistas (como el caso) pueden y deben usarse para evitar colisiones e indicar si se requiere una instancia.

una de las mejores prácticas que tuve fue el uso de formateadores de código (astyle y uncrustify son 2 ejemplos). los formateadores de código pueden destruir el formato del código: configure el formateador y deje que haga su trabajo. en serio, olvídate del formato manual y entra en la práctica de usarlos. ahorrarán una tonelada de tiempo.

según lo mencionado, ser muy descriptivo con nombrar. también, sea muy específico con el alcance (tipos de clase/datos/espacios de nombres/espacios de nombres anónimos). en general, me gusta mucho la forma escrita común de Java, que es una buena referencia y similar a C++.

como para línea específico/nomenclatura, esto es una pequeña muestra similar a lo que yo uso (variables/argumentos se lowerCamel y esto sólo demuestra una parte de las funciones del lenguaje):

/** MYC_BEGIN_FILE_ID::FD_Directory_nanotimer_FN_nanotimer_hpp_::MYC_BEGIN_FILE_DIR::Directory/nanotimer::MYC_BEGIN_FILE_FILE::nanotimer.hpp::Copyright... */ 
#ifndef FD_Directory_nanotimer_FN_nanotimer_hpp_ 
#define FD_Directory_nanotimer_FN_nanotimer_hpp_ 

/* typical commentary omitted -- comments detail notations/conventions. also, no defines/macros other than header guards */ 

namespace NamespaceName { 

/* types prefixed with 't_' */ 
class t_nanotimer : public t_base_timer { 
    /* private types */ 
    class t_thing { 
     /*...*/ 
    }; 
public: 
    /* public types */ 
    typedef uint64_t t_nanosecond; 

    /* factory initializers -- UpperCamel */ 
    t_nanotimer* WithFloat(const float& arg); 
    /* public/protected class interface -- UpperCamel */ 
    static float Uptime(); 
protected: 
    /* static class data -- UpperCamel -- accessors, if needed, use Get/Set prefix */ 
    static const t_spoke Spoke; 
public: 
    /* enums in interface are labeled as static class data */ 
    enum { Granularity = 4 }; 
public: 
    /* construction/destruction -- always use proper initialization list */ 
    explicit t_nanotimer(t_init); 
    explicit t_nanotimer(const float& arg); 

    virtual ~t_nanotimer(); 

    /* 
     public and protected instance methods -- lowercaseCamel() 
     - booleans prefer is/has 
     - accessors use the form: getVariable() setVariable(). 
     const-correctness is important 
    */ 
    const void* address() const; 
    virtual uint64_t hashCode() const; 
protected: 
    /* interfaces/implementation of base pure virtuals (assume this was pure virtual in t_base_timer) */ 
    virtual bool hasExpired() const; 
private: 
    /* private methods and private static data */ 
    void invalidate(); 
private: 
    /* 
     instance variables 
     - i tend to use underscore suffix, but d_ (for example) is another good alternative 
     - note redundancy in visibility 
    */ 
    t_thing ivar_; 
private: 
    /* prohibited stuff */ 
    explicit t_nanotimer(); 
    explicit t_nanotimer(const int&); 
}; 
} /* << NamespaceName */ 
/* i often add a multiple include else block here, preferring package-style inclusions */  
#endif /* MYC_END_FILE::FD_Directory_nanotimer_FN_nanotimer_hpp_ */ 

Answer 11

Por lo que es vale la pena, Bjarne Stroustrup, el autor original de C++ tiene su propio estilo favorito, que se describe aquí: http://www.stroustrup.com/bs_faq2.html