2010-08-21 6 views
13

gcc 4.4.4 c89Estándar para typedef'ing

Me pregunto si hay alguna norma que se deba seguir al crear tipos.

por ejemplo:

personas
typedef struct date 
{ 
} date_t; 

También he visto poner una capital como esta:

typedef struct date 
{ 
} Date; 

O para las variables

typedef unsigned int Age; 

o esta

typedef unsigned int age_t; 

¿Hay algún estándar que deba seguirse? Personalmente prefiero la fijación de publicaciones con un _t.

Muchas gracias por todas las sugerencias,

+2

Creo que la terminología más habitual es 'convencional' en lugar de 'estándar'. Buena pregunta. Creo que el proyecto de openssl para uno usa la convención de typedef struct objname_st {...} objname. –

Respuesta

5

Gran parte de esto se reduce a las preferencias personales, con la clave de ser coherente (o si tiene una convención de la empresa, úselo). El siguiente artículo tiene algunas guías de nomenclatura:

http://www.montefiore.ulg.ac.be/~piater/Cours/Coding-Style/

Tenga en cuenta que cambia la parte de '' t':

typedef struct node_t { 
    void *content; 
    struct node_t *next; 
} Node; 

typedef enum season_t { SPRING, SUMMER, FALL, WINTER } Season; 

Hubo un debate anterior sobre convenciones C nomenclatura aquí:

What are the most common naming conventions in C?

+0

¿No sería mejor tener el nodo como el nombre de la etiqueta y node_t como el tipo? Gracias. – ant2009

+4

Dado que '_t' está reservado para POSIX, sugeriría no utilizar '_t' en absoluto y elaborar una convención de nombres que tenga sentido para usted (por ejemplo, vea la respuesta de @ casablanca). Solo cité el artículo, que es solo una opinión. –

4

El estilo es una cosa muy personal y altamente subjetiva, insto encarecidamente que utilice simplemente lo que quiera, o lo que sea convenciones se utilizan en su organización.

+10

Pero las convenciones evolucionan según la experiencia. ¿Por qué no intentar aprovechar esa experiencia? –

3

Siga lo que el resto de la gente hace por su proyecto para que todo se mantenga coherente. De lo contrario, ambos son aceptables técnicamente.

27

Si está trabajando en una plataforma que sigue los estándares POSIX debe tener en cuenta que cualquier identificador que termine en _t está reservado para los tipos definidos POSIX por lo que no es aconsejable seguir la misma convención para sus propios tipos.

3

No creo que haya ninguna convención de nomenclatura "estándar". De hecho, varían tan tremendamente entre proyectos (y también entre otros lenguajes como C++ o Java) que personalmente he adoptado camelCase en todos los idiomas.

Siempre defino mis estructuras a través de typedef, así que solo uso el nombre que le hubiera dado de lo contrario (esto también es lo que hace la API Win32). En caso de que necesite una estructura de autorreferencia, que una de prefijo _ al nombre de la estructura en bruto:

typedef struct _Node { 
    _Node *next; 
} Node; 
+0

Por supuesto, por alguna razón, la convención C# y .NET parece estar en mayúscula con la primera letra del método y los nombres de campo. –

+6

Se reservan los nombres con un guión bajo seguido de una letra mayúscula u otro guión bajo. (Los nombres con un guión bajo seguido de una letra minúscula pueden reservarse según el alcance; es más fácil evitar los subrayados iniciales). Http://stackoverflow.com/questions/228783/what-are-the-rules-about-using -un-guión bajo-en-ac-identificador/228797 # 228797 – jamesdlin

1

En general la mayoría de lenguajes permiten el uso de SentenceCase para las clases o tipos no estandarizados. Encuentro que esta es la mejor práctica y, en los idiomas que lo permiten, también uso espacios de nombres o módulos para evitar conflictos. En idiomas que no (como C), un prefijo donde sea necesario nunca se extravía.Para usar un ejemplo de varios lenguajes para algo que estoy trabajando actualmente en:

C: typedef uint32_t CpfsMode; 
C++: namespace Cpfs { typedef uint32_t Mode; } 
Python: cpfs.Mode = int 
7

es posible que sólo basta con utilizar

typedef struct toto toto; 
  1. El (etiqueta) struct toto y la typedef nombre toto (identificador) están en diferentes C "namescopes" así que son compatibles, pero apuntan al mismo tipo al final.
  2. Como una ventaja adicional, esto también es compatible con C++, que generalmente implícitamente tiene un typedef.
  3. Como otra ventaja, esto inhibe a declarar una variable toto que puede ser bastante confuso a veces.
+0

Estoy contento de haber bajado y haber tenido que mirarme a la cara por no pensar directamente sobre esto. – bzeaman

Cuestiones relacionadas