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

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 los archivos .h y .cpp para la misma biblioteca están en el mismo directorio. Para evitar conflictos con los nombres, nombres de archivo son a menudo Anteponer el nombre de la empresa y / o nombre de la biblioteca. MYLIB estará en la ruta de búsqueda de cabecera MiApl, etc. No soy un fan de los nombres de archivo como prefijo, pero me gusta la idea de ver el #include y sé dónde colocar el archivo de cabecera pertenece. No odio a este enfoque de la organización de archivos, pero yo creo que debe haber una mejor manera.

Desde que estoy empezando un nuevo proyecto, quiero solicitar algunas ideas de organización directorio. 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 

archivos y .cpp (visible sólo para la biblioteca de peligro) .h archivos privados se almacenan en el directorio src (src es a veces llamado lib). archivos de cabecera públicos se organizan en una estructura de directorios / lib e incluyeron a través <ProjectName/LibraryName/headerName.h>. Los nombres de archivo no tienen el prefijo nada. Si alguna vez necesitaba para empaquetar MYLIB para ser utilizado por otros equipos, yo podría simplemente cambiar mi makefile para copiar los archivos binarios apropiados y el conjunto include / proja directorio.

Una vez que los archivos se comprueban en el control de la fuente y la gente comienza a trabajar en ellos, será difícil cambiar la estructura de directorios. Es mejor hacer las cosas bien en el primer momento.

Cualquier persona con experiencia en la organización del código fuente de esta manera? Cualquier cosa que no me gusta de ella? Si usted tiene una mejor forma de hacerlo, mucho me gustaría saberlo.

Answer 1

Bueno, todo depende de lo grande que estos proyectos son. Si sólo tiene unos pocos archivos, y luego golpear a todos en una sola carpeta.

Hay demasiadas carpetas cuando no se tiene muchos archivos para administrar es en mi opinión una exageración. Se pone molesto excavación dentro y fuera de las carpetas cuando sólo tiene unos pocos archivos en ellos.

Además, depende de quién está usando este material. Si estás escribiendo una biblioteca y que va a ser utilizado por otros programadores, entonces es bueno para organizar las cabeceras que quieran utilizar en una carpeta incluir. Si va a crear una serie de bibliotecas y la publicación de todos ellos, a continuación, su estructura podría funcionar. Pero, si son bibliotecas independientes, y el desarrollo no es todo hecho juntos y consiguen versionado y liberados en diferentes momentos, sería mejor de pegarse con tener todos los archivos para un proyecto localizable dentro de una carpeta.

De hecho, yo diría que mantener todo en una carpeta, hasta llegar a un punto en el que encuentre su unmanagable, a continuación, reorganizarse en un plan inteligente de dividir la fuente hasta en carpetas como usted ha hecho. Usted probablemente sabe lo que tiene que ser organizada de los problemas que se ejecutan en.

KISS es por lo general siempre es la solución de programación -> mantener todo tan simple como sea posible

.

Answer 2

¿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>

Eso te dice dónde son. En cuanto a la segunda opción, yo personalmente conseguir realmente molesto cuando tengo un archivo de cabecera o de código abierto, y tienen que navegar por la estructura del directorio para encontrar la otra y abrirlo. Con su segundo ejemplo, si usted hubiera src/mylib/class_a.cpp abierta, y quería editar el encabezado, en muchos editores que tendría que volver dos niveles, a continuación, en include/ProjA antes de encontrar la cabecera. ¿Y cómo vamos a saber que la cabecera está en el subdirectorio ProjA sin alguna otra pista externa? Además, es muy fácil para un archivo o la otra para conseguir trasladado a un lugar diferente que "mejor" representa la forma en que se utiliza, sin el archivo alternativo está moviendo. Simplemente me da dolores de cabeza cuando lo encuentro en mi trabajo (y que tienen algunas partes de nuestro código base, donde la gente hacía cada problema potencial que acabo de mencionar.)

Answer 3

He probado ambos métodos. En lo personal, me gusta el primero mejor. Entiendo la necesidad de poner todo en las guías más específicas, pero causa una gran cantidad de exceso de complicación.

Yo suelo usar esta regla: las aplicaciones y en la casa bibliotecas utilizar el primer método. bibliotecas de código abierto públicos utilizan el segundo método. Cuando se está liberando el código, que ayuda mucho si los archivos de inclusión están en un directorio independiente.