Cerrada. Esta pregunta está
fuera de tema . Actualmente no acepta respuestas.
Comentarios
Responder
Si sigo escribiendo más código, habrá un momento en el que me resultará difícil organizar el código.
Este es su problema: conseguir la organización correcta, y el estilo debería fluir más fácilmente.
No espere para organizar su código: mantenga su código organizado sobre la marcha. Aunque el lenguaje no lo hace por usted, el código aún debería estar organizado en módulos con bajo acoplamiento y alta cohesión.
Estos módulos entonces naturalmente proporcionan un espacio de nombres. Abrevie el nombre del módulo (si es largo) y antepone los nombres de las funciones con su módulo para evitar colisiones.
A nivel de identificadores individuales, estos están aproximadamente en orden creciente de subjetividad:
- elija una convención y cúmplala
- por ejemplo,
function_like_this(struct TypeLikeThis variable) es común
-
definitivamente evita la notación húngara (lo siento JNL)
-
a menos que estés dispuesto a usarla como se pretendía originalmente, lo que significa la notación de aplicaciones de Simonyi en lugar de la terrible versión de los sistemas
¿Por qué? Podría escribir un ensayo sobre esto, pero en cambio le sugiero que lea este artículo de Joel Spolsky, y luego busque algo más si está interesado. Hay un enlace al documento original de Simonyi en la parte inferior.
-
Evite las definiciones de tipo de puntero a menos que sean tipos de cookies realmente opacos; solo confundir las cosas
struct Type *ok; typedef struct Type *TypePtr; TypePtr yuck;
¿Qué quiero decir con un tipo de cookie opaco ? Me refiero a algo que se usa dentro de un módulo (o biblioteca, o lo que sea) que debe pasarse al código del cliente, pero ese código del cliente puede «t usar directamente. Simplemente lo devuelve a la biblioteca.
Por ejemplo, una biblioteca de base de datos podría exponer una interfaz como
/* Lots of buffering, IPC and metadata magic held in here. No, you don"t get to look inside. */ struct DBContextT; /* In fact, you only ever get a pointer, so let"s give it a nice name */ typedef struct DBContexT *DBContext; DBContext db_allocate_context(/*maybe some optional flags?*/); void db_release_context(DBContext); int db_connect(DBContext, const char *connect); int db_disconnect(DBContext); int db_execute(DBContext, const char *sql);
Ahora, el contexto es opaco para el código del cliente, porque no puede mirar dentro. Simplemente devuélvalo a la biblioteca. Algo como FILE también es opaco, y un descriptor de archivo entero también es una cookie , pero no es opaco.
Una nota sobre el diseño
Usé la frase bajo acoplamiento y alta cohesión arriba sin explicación, y me siento un poco mal por eso. Puede buscarlo y probablemente encontrará buenos resultados, pero trataré de abordarlo brevemente (nuevamente, podría escribir un ensayo pero trataré de no hacerlo).
La biblioteca de base de datos esbozada arriba muestra acoplamiento bajo porque expone una pequeña interfaz al mundo exterior. Al ocultar los detalles de su implementación (en parte con el truco de las cookies opacas), evita que el código del cliente dependa de esos detalles.
Imagínese en lugar de la cookie opaca, declaramos la estructura de contexto para que su contenido sea visible, y eso incluye un descriptor de archivo de socket para una conexión TCP a la base de datos. Si posteriormente cambiamos la implementación para admitir el uso de un segmento de memoria compartida cuando el La base de datos se está ejecutando en la misma máquina, el cliente debe volver a compilarse en lugar de volver a vincularse. Peor aún, el cliente podría haber comenzado usando el descriptor de archivo, por ejemplo llamando a setsockopt para cambiar el tamaño del búfer predeterminado, y ahora también necesita un cambio de código. Todos estos detalles ils deben estar ocultos dentro de nuestro módulo donde sea práctico, y esto proporciona un bajo acoplamiento entre módulos.
El ejemplo también muestra alta cohesión , en el sentido de que todos los Los métodos del módulo están relacionados con la misma tarea (acceso a la base de datos). Esto significa que solo el código que necesita saber acerca de los detalles de implementación (es decir, el contenido de nuestra cookie) realmente tiene acceso a ellos, lo que simplifica la depuración.
También puede ver que tener una sola preocupación facilitó la elección de un prefijo para agrupar estas funciones.
Ahora, decir que este ejemplo es bueno es fácil (especialmente porque no lo es «ni siquiera completa), pero no te ayuda de inmediato. El truco consiste en observar, a medida que escribe y extiende su código, las funciones que hacen cosas similares u operan en los mismos tipos (que pueden ser candidatas para su propio módulo), y también las funciones que hacen muchas cosas separadas que no son » Realmente están relacionados y podrían ser candidatos para separarse.
Comentarios
Responder
En mi opinión 90 % del problema de nomenclatura se resuelve si tiene en cuenta tres cosas: a) haga que los nombres de sus variables y funciones sean tan descriptivos como posible, b) sea coherente en todo el código (es decir, si una función se llama addNumbers, una segunda función debería llamarse multiplyNumbers y no numbersMul) y c) intenta que los nombres sean cortos si es posible, ya que tenemos que escribirlos.
Dicho esto, si quieres echar un vistazo a otros aspectos de este tema, la página de Wikipedia sobre Convenciones de nomenclatura tiene una buena lista de cosas que debes tenga en cuenta. También tiene una sección en C y C ++:
En C y C ++, las palabras clave y los identificadores de biblioteca estándar están en su mayoría en minúsculas. En la biblioteca estándar de C, los nombres abreviados son los más comunes (por ejemplo, isalnum para una función que prueba si un carácter es alfanumérico), mientras que la biblioteca estándar de C ++ a menudo usa un guión bajo como separador de palabras (por ejemplo, out_of_range). Los identificadores que representan macros se escriben, por convención, usando solo letras mayúsculas y guiones bajos (esto está relacionado con la convención en muchos lenguajes de programación de usar identificadores en mayúsculas para constantes). Los nombres que contienen doble subrayado o que comienzan con un subrayado y una letra mayúscula están reservados para la implementación (compilador, biblioteca estándar) y no deben usarse (por ejemplo, reservado__ o _Reservado). [5] [6] Esto es superficialmente similar a stropping, pero la semántica difiere: los guiones bajos son parte del valor del identificador, en lugar de estar entre comillas (como es stropping): el valor de __foo es __foo (que está reservado), no foo (pero en un espacio de nombres diferente).
Comentarios
Respuesta
La única restricción estricta en C es que no hay espacios de nombres. Por lo tanto, debe encontrar una manera de hacer que la función rename() de su sistema de archivos sea distinta de la rename() función de su biblioteca multimedia . La solución habitual es un prefijo, como: filesystem_rename() y media_rename().
El otro consejo general es: quédese coherente dentro de un proyecto o un equipo. Se mejorará la legibilidad.
Comentarios
Responda
SI ESTÁ BUSCANDO UN GLOBAL FORMATO ACEPTADO
MISRA / JSF / AUTOSAR cubre casi el 100% de todos y cada uno de los estándares de la industria para nombrar y organizar el código C / C ++. El problema es que no serán gratis para conseguirlas, es decir, cada una de las guías cuesta algo de dinero. Sé que el libro estándar de codificación MISRA 2008 C / C ++ probablemente cuesta alrededor de 50 USD.
Puede considerarlos como la referencia de Harvard para la bibliografía y la lectura adicional cuando escribe una revista. He usado MISRA y es una buena manera de nombrar sus funciones y variables, y organizarlas para un uso adecuado.
SI ESTÁ BUSCANDO ALGO TEMPORAL
Las referencias que proporcionaste para Python y Java están bien, supongo. He visto gente adoptando el estilo javadoc comentando, nombrando y organizando el código. De hecho, en mi último proyecto, tuve que escribir código C ++ en funciones / nombres de variables similares a Java. Dos razones detrás de esto:
1) Aparentemente fue más fácil de seguir.
2) Los requisitos del código de producción no tocaron el terreno de los estándares de sistemas de software críticos para la seguridad.
3) El código heredado estaba (de alguna manera) en ese formato.
4) Doxygen permitía comentar el estilo de Javadoc. En ese momento, estábamos usando doxygen para generar documentación para los chicos de producción.
Muchos programadores se opondrán a esto, pero personalmente creo que no hay nada de malo en adoptar el estilo de javadoc para nombrar funciones / variables en C / C ++. SÍ POR SUPUESTO, las prácticas de organización de su control de flujo, seguridad de subprocesos, etc. deben abordarse independientemente. Sin embargo, no soy un solicitante aquí. Tampoco sé qué tan estrictos son los requisitos de formato de su código de producción. Sin desviarlo a un área fuera del tema, le sugiero que revise sus requisitos, averigüe qué tan dependiente está de una convención de nomenclatura específica y elija una solución mencionada en la mía y en otras «respuestas
¡Espero que esto haya ayudado !?
Comentarios
Respuesta
Algunas cosas importantes a considerar al nombrar serían:
-
Observa el tipo actionObject o ObjectAction. (Object no para C. Pero en general cuando vas a otros lenguajes orientados a objetos) Esto debería ayudar
-
El descanso sería CONSISTENTE, breve y descriptivo con seguridad.
- Además, tenga un único propósito de cada variable y función definida, por ejemplo: si es para almacenar un valor temporalmente, asígnele el nombre nTempVal para int
- Las variables deben ser sustantivos y los métodos deben ser verbos.
Comentarios
Responder
La mayoría de las respuestas son buenas, pero quiero decir algunas cosas sobre los nombres convenciones para bibliotecas y archivos incluidos, similar al uso de espacios de nombres en otros lenguajes como C ++ o Java:
Si construye una biblioteca, busque un prefijo común para sus símbolos exportados, es decir, funciones globales, typedefs y variables. Esto evitará conflictos con otras bibliotecas e identificará las funciones como provenientes de la suya. Esta es una pequeña parte de las notaciones húngaras de las aplicaciones.
Tal vez vaya más allá y agrupe los símbolos exportados: libcurl usa curl_ * para símbolos globales, curl_easy_ *, curl_multi_ * y curl_share_ * para las diferentes interfaces.Entonces, además de usar curl_ * para todas las funciones, han agregado otro nivel de «espacios de nombres» para las diferentes interfaces: llamar a una función curl_easy_ * en un identificador curl_multi_ * ahora se ve mal, vea los nombres de las funciones en http://curl.haxx.se/libcurl/c/
Manteniendo las reglas para los símbolos exportados, debes usarlas para funciones estáticas en #include archivos ed: Intente encontrar un prefijo común para estas funciones. ¿Quizás tiene funciones de utilidad de cadena estática en un archivo llamado «my_string»? Prefije todas esas funciones con my_string_ *.
Comentarios