C++ fuente del proyecto de diseño de código

Question

Una de las formas populares para organizar directorio del proyecto es más o menos así:

 
MyLib 
    +--mylib_class_a.h 
     mylib_class_a.cpp 
     mylib_library_private_helpers.h 
     mylib_library_private_helpers.cpp 

MyApp 
    +--other_class.h 
     other_class.cpp 
     app.cpp 

app.cpp:

#include "other_class.h" 
#include <mylib_class_a.h> // using library MyLib 

Todos .h y .cpp archivos de la misma biblioteca son en el mismo directorio. Para evitar la colisión de nombres, los nombres de los archivos suelen ser prefijados con el nombre de la empresa o el nombre de la biblioteca. MyLib estará en la ruta de búsqueda del encabezado de MyApp, etc. No soy partidario de poner nombres de archivos prefijados, pero me gusta la idea de mirar el #include y saber exactamente a dónde pertenece ese archivo de encabezado. No odio este enfoque de organizar archivos, pero creo que debería haber una mejor manera.

Como comienzo un nuevo proyecto, deseo solicitar algunas ideas de organización de directorios. Actualmente me gusta esta estructura de directorios:

 
ProjA 
    +--include 
      +--ProjA 
        +--mylib 
          +--class_a.h 
        +--app 
          +--other_class.h 
    +--src 
     +--mylib 
       +--class_a.cpp 
        library_private_helpers.h 
        library_private_helpers.cpp 
     +--app 
       +--other_class.cpp 
       app.cpp 
       util.h 

app.cpp:

#include "util.h" // private util.h file 
#include <ProjA/app/other_class.h> // public header file 
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib 
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision 
#include <class_a.h> // not ProjA/mylib/class_a.h 
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h 

.cpp archivos y privado (sólo visible para la biblioteca inmediata) .h archivos se almacenan en el directorio src (src es a veces llamado lib). Los archivos de encabezado públicos están organizados en una estructura de directorio de proyecto/lib e incluidos a través de <ProjectName/LibraryName/headerName.h>. Los nombres de archivo no tienen prefijos. Si alguna vez necesité empaquetar MyLib para ser utilizado por otros equipos, simplemente podría cambiar mi archivo MAKE para copiar los archivos binarios apropiados y todo el directorio include/ProjA.

Una vez que los archivos se controlan en el control de origen y las personas comienzan a trabajar en ellos, será difícil cambiar la estructura del directorio. Es mejor hacerlo bien en el primer momento.

¿Alguien con experiencia organizando código fuente como este? ¿Algo que no te gusta de él? Si tienes una mejor manera de hacerlo, me gustaría mucho escucharlo.

Answer 1

Bueno, todo depende de qué tan grandes sean estos proyectos. Si solo tiene unos pocos archivos, agréguelos a todos en una sola carpeta.

Demasiadas carpetas cuando no tienes muchos archivos para administrar es, en mi opinión, excesiva. Se hace molesto cavar dentro y fuera de las carpetas cuando solo tienes algunos archivos en ellas.

Además, depende de quién use estas cosas. Si está escribiendo una biblioteca y va a ser utilizada por otros programadores, entonces es bueno organizar los encabezados que desean usar en una carpeta de inclusión. Si está creando varias bibliotecas y las está publicando todas, su estructura podría funcionar. Pero, si se trata de bibliotecas independientes, y el desarrollo no se hace todo junto y se actualizan y publican en diferentes momentos, sería mejor que se quedara con todos los archivos de un proyecto localizable dentro de una carpeta.

De hecho, yo diría que guardes todo en una carpeta, hasta que llegues a un punto en que descubras que es inmanejable, luego reorganízate en un inteligente esquema de dividir la fuente en carpetas como lo has hecho. Probablemente sabrá cómo debe organizarse a partir de los problemas que encuentra.

KISS suele ser siempre la solución en programación -> mantener todo lo más simple posible.

Answer 2

He intentado ambos métodos. Personalmente, me gusta el primero mejor. Entiendo el impulso de poner todo en directorios más específicos, pero causa muchas complicaciones.

Normalmente uso esta regla: las aplicaciones y las bibliotecas internas usan el primer método. Las bibliotecas públicas de código abierto usan el segundo método. Cuando libera el código, ayuda mucho si los archivos incluidos están en un directorio separado.

Answer 3

Por qué no hacer algo como la primera, sólo utilice el directorio que reside en MyLib como parte de la directiva de inclusión, lo que reduce la fijación previa tonta:

#include <MyLib/ClassA.h> 

que le indica dónde son. En cuanto a la segunda opción, personalmente me enojo mucho cuando tengo un encabezado o archivo fuente abierto, y tengo que navegar a través de la estructura del directorio para encontrar el otro y abrirlo. Con su segundo ejemplo, si tenía src/mylib/class_a.cpp abierto, y quería editar el encabezado, en muchos editores tendría que retroceder dos niveles, luego en include/ProjA antes de encontrar el encabezado. ¿Y cómo vamos a saber que el encabezado está en el subdirectorio ProjA sin alguna otra pista externa? Además, es demasiado fácil para un archivo u otro moverse a un lugar diferente que "mejor" representa cómo se usa, sin mover el archivo alternativo. Simplemente me da dolores de cabeza cuando lo encuentro en mi trabajo (y tenemos algunas partes de nuestra base de código donde la gente hacía todos los problemas potenciales que acabo de mencionar).