1. Inicio
  2. Pregunta y respuesta
  3. Nombramiento en C++: read_input() vs. readInput()

Nombramiento en C++: read_input() vs. readInput()

2009-11-23 8 views
8

¿Qué convención de nomenclatura es más preferible en C++? El método de subrayado o el método camelCase? He codificado en Java por un tiempo y estoy acostumbrado a las convenciones de nombres de camelCase. ¿Cuál es más frecuente?Nombramiento en C++: read_input() vs. readInput()

Además, al definir una clase, ¿hay algún tipo de pedido preferido de variables/métodos privados/públicos/protegidos?
¿Los amigos generalmente se ponen al final?
¿Qué pasa con typedefs, vienen en la parte superior de la definición de clase?

Fuente

2009-11-23 user855

+2

Solo quería agregar, lo marcaría como wiki comunitario y subjetivo. –

+0

Un duplicado de: http://stackoverflow.com/questions/1776291/function-names-in-c-capitalize-or-not incluso si el título es un poco diferente. –

+0

Muy probablemente un duplicado de: http://stackoverflow.com/search?q=c%2B%2B+convention Hay toneladas de estos subprocesos. –

Respuesta

7

Todo esto es muy subjetivo, pero en general para C++ que hago:

camelCase de funciones y variables.

PascalCase para las clases.

public: 
protected: 
private:

En las clases.

Editar: Olvido estos 2:

Sí, friend al final, typedef ya sea al principio si se utilizan en la clase, o después si utilizan la clase (por razones obvias).

Fuente

2009-11-23 19:31:48

+0

Yo diría lo mismo. Aunque tiendo a no usar mucho a los amigos, en C++ eso es;) –

+2

@Steven - Espero que no uses a tus amigos en la vida real. 8v) –

+3

Bueno, simplemente evito amigos en general :) –

3

subrayados son a menudo más frecuentes en unix o código de plataforma cruzada.

código de ventanas tiende a ser camello entubado

general pública, protegida, privada es lo que esperaría - pero tal vez eso es más de mi C# tiempo.

Fuente

2009-11-23 19:32:21 dice

0

Uso los guiones bajos para las variables locales; ALL_UPPERCASE para macros y constantes; camelCase para nada y CamelCase para todo lo demás.

Siempre utilizo structs y never classes, y por lo tanto comienzo con public: (sin especificarlo) y luego lo pongo private: al final.

Todo esto es muy subjetivo y no hay una respuesta correcta o incorrecta.

Fuente

2009-11-23 19:46:03

21

Prefiero tomar la ruta de refuerzo y hacer coincidir la biblioteca estándar. Eso significa lower_case_names. Me gusta que mi código sea coherente con respecto a la STL.

Fuente

2009-11-23 19:53:53 GManNickG

+1

Yo solía hacer eso también, pero un proyecto en el que trabajé decía que, a veces, resulta difícil identificar al instante qué código escribió y cuál es de std :: si lo hace usando namespace std; Eso tiene sentido para mí, pero voto favorable para usted, señor, ya que también me gusta este estilo. –

+4

@ Adam: ¿por qué sería deseable diferenciar ópticamente entre código STL y código propio? Eso nunca tuvo sentido para mí, sin embargo, la gente lo usa en todo tipo de entornos (no solo en C++). Para eso * están los espacios de nombres * y hacen un trabajo increíblemente bueno. –

+0

@Konrad: Sí, lo entiendo, pero a veces no quieres usar std :: o myown :: frente a todo, así que usas el espacio de nombres ... Luego, a medida que avanzas, ves 'algo .push_back (item) 'then' something.sort() 'es this std :: list :: sort(), o myown :: objectwithalist :: sort()? De nuevo, me vi obligado a seguir esto al mismo tiempo, y ha reemplazado lentamente a mis propios métodos estándar. –

0

¿Qué convención de nomenclatura es más preferible en C++? El método 'subrayado' o el método camelCase? Tengo codificado en Java por un tiempo y estoy acostumbrado a las convenciones de camelCase . ¿Cuál es más prevalente de ?

Yo diría 'simplemente quédate con lo que sabes sobre esto si estás empezando a escribir tus propias bibliotecas', ambas se usan con regularidad.

Además, al definir una clase, ¿hay alguna preferencia en el pedido de variables/métodos privados/públicos/protegidos?

Esto varía según el programador/equipo. Ordeno por categoría Utilizo una categoría para "métodos internos/privados", y esa categoría generalmente es penúltima (la última implementación está prohibida).

¿Los amigos suelen ponerse al final?

Los uso raramente; Los inserto sobre la dependencia (método), de lo contrario, después de la categoría constructor/destructor.

¿Qué pasa con typedefs, vienen en la parte superior de la definición de clase?

Ahí es donde los puse.

Si desea entrar en detalles, hay convenciones de codificación públicamente disponibles. Como ya tienes un fondo Java, podrás cortar fácilmente el 'sabor' en ellos.

Fuente

2009-11-23 19:59:58 justin

6

Normalmente respeto las tradiciones de la plataforma/entorno en el que estoy programando, excepto en proyectos multiplataforma en C/C++ donde soy neutral. Cuando programo C + raw Win32 tiendo a usar la notación húngara para las variables (tipo o prefijos semánticos). Cuando programo MFC variables de miembro de m_, etc. Lo único que no me resulta fácil es la convención de Unix/POSIX open_device_driver frente al estilo de cabina de OpenDeviceDriver.

Fuente

2009-11-23 20:00:49

+0

+1. Cuando en Roma, etc etc ... – Macke

+1

+1. ... haz lo que hacen los rumanos – Joe

3

Lo más importante aquí es que te mantengas constante. Si está incorporando el código de otras personas en su proyecto, quédese con el método que esté usando. Si planea contribuir con este código para, por ejemplo, un proyecto de software de código abierto en el futuro, intente cumplir sus convenciones de codificación. Si está escribiendo todo su código desde cero, le diría que siga las convenciones que está acostumbrado a usar. Esto te ayudará especialmente cuando regreses a tu código más tarde y trates de comprender lo que escribiste.

En cuanto a las especificaciones de acceso de estructura/clase, normalmente verá miembros públicos primero en la lista, seguidos por protegidos y luego privados (para aumentar el control de acceso). Esto se hace principalmente por razones de legibilidad. Cuando otras personas usan su código, serán estos miembros públicos con los que interactuarán, por lo que colocarlos en la parte superior de la declaración los hace más fáciles de encontrar. Ordenar miembros de esta manera mantiene la mayor probabilidad de que se utilice la información más cercana a la cima. No veo el friend usado con demasiada frecuencia, por lo que no recuerdo ningún patrón en cuanto a su uso. typedef por lo general aparece en la parte superior, de modo que cuando se mira el resto de la clase, el lector ya conoce sus tipos personalizados (también por razones de legibilidad, typedef s suelen agruparse y no se intercalan con las declaraciones de los miembros).

Hay una serie de convenciones de codificación existentes que se utilizan comúnmente, y lo único que tienen en común es un estándar. Independientemente del sistema con el que vaya, incluso si lo define usted mismo, es útil si tiene un documento (o una página de código de ejemplo) que describa la convención de codificación. La consistencia mejora la legibilidad, especialmente cuando revisa código anterior en algún momento en el futuro.

Aquí hay un par convenciones de codificación que tal vez le dará algunas ideas:

Fuente

2009-11-23 20:23:52 bta

0

Décadas de codificación como un trabajo me dio algo de enfermedad a mis dedos. Cada vez que uso mi meñique para presionar la tecla [MAYÚS] en mayúscula, siento un dolor leve.

Así que preferí snake_notation. Usando la utilidad AutoHotKey, asigné la combinación [alt] + [espacio] a 'carácter de subrayado' de serpiente. Es poco incómodo para mi pulgar presionar [alt], pero es mejor que usar el dedo meñique. (En realidad [ctrl] + [espacio] es mucho mejor, pero VisualStudio usa esta combinación como intellisense). Además, creo que es más rápido que camelCase.

Deseo i-rocks lanza un nuevo teclado con 'tecla de subrayado' para los programadores que prefieran snake_notation.

Fuente

2017-11-19 10:47:03 user1276700

Cuestiones relacionadas

 Cuestiones relacionadas