una tecnicas pasos para organizar organizacion oficina marcar manera fisico empresa eficaz documentos como clasificacion carpetas archivos archivo c code-organization

tecnicas - pasos para organizar un archivo



mejores artículos sobre la organización de archivos de código en C (4)

Específico para unix (y no para c , natch), pero no obstante:

Recursivo Hacer Considerado Dañino

Con la estructura de construcción descrita, puede permitirse usar muchos archivos. Entonces, cada unidad lógica obtiene un encabezado y un archivo fuente.

¿Me pueden recomendar qué debo leer / aprender para poder crear un código bien organizado en C?

Una de las cosas que quiero aprender son los principios del proyecto de división en archivos .h y .c, qué va donde y por qué, nombres variables, cuándo usar variables globales ...

Estoy interesado en libros y artículos que tratan este problema específico.



Creo que la mejor lectura educativa que obtendrás sobre este tema es leer algo así como la fuente Linux Kernel. Tiene un buen diseño de fuente, y es básicamente el proyecto estándar de C grande. Aquí hay una guía sobre cómo los archivos fuente también deben juntarse para la fuente BSD.

En serio, solo comienza a leer la fuente de Kernel y tener una idea de cómo se combinan todas las cosas. Es un proyecto muy bien planeado, obviamente.


En cuanto al diseño de los archivos, no hay demasiadas alternativas.

El particionamiento es típicamente uno de los siguientes (el paquete aquí es una sola biblioteca o binario):

  1. ... / project /.../ package / module. {c, h}
  2. ... / project /.../ {src, include} / package / module. {c, h} // los encabezados que no son de interfaz van a src
  3. ... / project /.../ package / {src, include} / module. {c, h} // encabezados que no son de interfaz van a src

La partición (1) es conveniente porque todos los archivos que pertenecen a un paquete particular se almacenan en un solo directorio, por lo que el paquete puede moverse fácilmente, pero con este enfoque separar los encabezados de API de los privados y detectar los cambios de API no es trivial. (2) y (3) son muy similares, hacen que la liberación de API y la detección de cambios de API sean triviales, mientras que (2) es un poco más fácil para el caso cuando siempre liberas todo el proyecto y (3) es un poco mejor cuando lanzas paquetes individuales (por ejemplo, para parches)

En cualquier proyecto de C / C ++ suele haber los siguientes paquetes comunes:

  1. Macros comunes y tipos de datos
  2. Paquete de registro
  3. Paquete de arranque de la aplicación (en caso de que haya más de 1 binario en el proyecto).