Throughout this series we’ll walk through how to setup and compile your first C++ program. Hopefully, this should be your initial step in understanding C++ so that you can aim to develop whatever program you desire. However, before we get there, we must first understand the fundamentals, how to organize our code, how to compile it, and then we can begin to explore to our hearts content.
I utilize the same base directory structure for each application I design. Albeit, I sometimes deviate from this initial structure (adding and/or removing directories), the same base directory structure works for most of the applications I design. I encourage you to do the same. Although you may find various directory structures discussed here or there useful, you might want to play around with them a bit, until you’ve tailored one that suites your own personalized needs. Until then, let’s discuss the basics.
The first and probably most important directory for each of my
applications is the bin directory. The
word bin stands for binaries, and
there should reside (at least) two directories within this one, which are a debug and release directory. These directories will (each) contain our
compiled code. The debug directory will contain code that is intended for
debugging, troubleshooting, and general testing of our compiled code. Now,
whereas our debug directory is to
hold our yet stable testable code, our release
directory should contain our stable, sharable, and (yes) releasable code.
The second directory that we’ll discuss here is a doc directory. Which, if you’ve guessed
it from its name, it should hold any and all documentation (or notes)
concerning your application. (This includes configuration files,
Sometimes denoted as inc, the next directory on our list is the include directory. An include directory can hold various things, depending on the nature of your application, language it’s written in, and more. In our case, sense we’ll be writing your initial application in C, we’re going to utilize our include directory for header files. These files will be essentially “included” into our code to bring in class and function declarations, macro definitions, along with any other shared resources that we’d like to store in there. These files are commonly denoted by a *.h, or a *.hpp extension, and become more understood as they’re utilized. For now, just know that header files allow you bring in various function declarations for pre-written code using the #include directive, and we’ll dive deeper into these file types as we advance throughout this series.
Next, let’s discuss what a lib directory is. Lib, in our case, is shorthand for library, or libraries. Although, you may write many applications without the need, or use of a third-party library, this is what this directory would be used for. Remember, many applications are built off the backs of pre-written code, libraries, and fundamental concepts that have already been discovered and optimized. There no need in re-inventing the wheel if there’s already an optimal solution that you can simply plugin to your application. Libraries are a great and fundamental asset to have when leveraged correctly, and could hasten the development of your application(s).
Albeit, the spice directory isn’t commonly found on many popular directory structure lists, once you understand its use case you should find it as useful as I do. The name spice implies extra, with a hint of instability. In essence, smaller classes and/or functions that are abstract and conceptual in nature should be placed here. Furthermore, any code that feels pre-mature, or as though it should be tested to identify whether it should eventually stay within the overall product, should go here. This is where the term spice comes from. Because the code that resides here isn’t considered a necessary or core part of our application, and it adds extra flavor to it. If the code ends up growing into something more substantial or as a core part of the application than it should migrate into our next directory; the source directory.
The src (or source) directory should contain your core application files. These are the files, classes, and functions that concretely define your application and its operations. Albeit, you could retain source code within this directory that is in work, or in development, the code should handle “clearly” core aspects or concepts of your application. This is what makes this folder unique from our spice folder. Whereas our spice folder holds code that is more conceptual in nature, our src folder holds code that more absolute in nature.
The test folder
is the final folder that we’ll talk about here. The test folder should contain all of your test code, unit tests, etc…
Although, you may not adhere towards the principles of test-driven development
for all projects, you should try to adhere towards it whenever possible. Tests
ensure that your application operates properly, and continues to do so while behaving as expected. We’ll go over the process of unit
tests within a future article. However, for the purposes of this endeavor we
won’t be incorporating any this time around.
Whether you set out to develop a large or small-scale application, it’s important to lay the ground work so that you can easily maintain an overall organized approach towards your application’s development. Ensuring that your code base is, not just organized, however, easy to maintain, can be a guiding mantra for some developers and an unbreakable principle for others. Try early on to set yourself up for success, and generally success follows.
If you would like to start your application with the above mentioned directory structure, you can gather more information, as well as download a pre-fabricated version of this structure at the following link. Please feel free to comment, contribute, or mention any issues below, or through the support link attached to this Github’s project page.