Several small problems that must be noticed in large C + + project __c++

Some problems may not matter for small C + + projects, but for large and medium C + + projects, these problems have become a big problem. What kind of project is small project, what kind of is medium and large project, I think ten million loc below for small projects, 10.5 million LOC for medium-sized projects, million loc above for large projects. Of course, can not simply as a measure of the number of lines of code, the previous few days of product refactoring, I used 4,230 lines of code to replace the original three thousand or four thousand lines of code, that the scale of the project is to use these twenty or thirty lines to calculate it, or with that three thousand or four thousand rows calculate it. Software is difficult to have an accurate metric, the number of lines as a reference standard bar.

It is also important to think about these issues when a large number of projects do not need to be considered in small projects.

1. Directory structure

Small projects may be a directory enough to put all the header files and source code and related engineering documents together, but the project is more than the time in the directory of the files are more, more than a view of the file is very inconvenient, if a variety of file licensing functions or categories to do some grouping will be more convenient, such as the search for a file is also very rapid. In this case, I think boost and Chrome are doing well, including their naming conventions are very uniform, and Ace does not do too well, all files in a directory, good hundreds of files, if you have a CVS or SVN Windows client installed, When you open Explorer, you also need to scan to see if the file is associated with a version library, making it slow to react and not feeling too good.

2. Module Division

A large project can not be as a whole project compiled at once, if there are hundreds of files, using a makefile or VS project, each compile time will be time-consuming, if you need to frequently debug, compile will be very consuming time. If the whole project is divided into several modules, different modules in the form of static library or dynamic library to organize, the modules can be compiled separately, separate test, and for many personal collaboration in parallel development is very advantageous. Because whether it's VSS, CVS and so these mainstream version management software for parallel development is not perfect, in fact this is not possible, because the software itself can not identify the program, like people to merge the program code, if several people will often modify the code of the same module, the conflict may be more, The number of conflict resolution not only affect the efficiency, but also affect the mood.

3. header File Hierarchy

Why is the hierarchy of the head file separate rather than directly dividing the module into the same problem? is to highlight its importance. If the module is not properly designed when the module is partitioned, it is likely to cause a header file to be referenced in a circular manner, so that the program cannot be compiled.

There are some special cases that need attention, such as Windows Winsock2.h and Windows.h conflict, if the first reference windows.h and then reference winsock2.h will be redefined. If you want to use the Win32 Socket API 2, you must first refer to winsock2.h and then reference windows.h, but if you refer to Windows in multiple files, it can lead to confusion if the order is poorly controlled, so the program cannot compile. Personally think the best way is to put the reference into a header file, It's called sysinc.h, and then all the header files for the compilation unit refer to Sysinc.h in the first line, and then all the. cpp files refer to the corresponding header file in the first line, which guarantees the winsock2.h and windows.h reference order.

4. Namespaces

The C language does not support namespaces, it used to be a prefix or suffix to avoid an identifier conflict, but that would make the identifier long, uncomfortable, and cumbersome to write (although now the IDE's support for IntelliSense has made this easy), it's always weird and not natural. As a result, later languages support namespaces (or similar functions), such as C + +, C #, Java, Python, and so on, so why not use this new feature in large C + + projects.

Using identifiers in different namespaces do not use a using namespace ns; Such statements introduce identifiers from the entire NS command space, thus losing the role of namespaces. Because it takes a prerequisite to do so, knowing that this will not conflict, but who can predict the future will not conflict. There were no problems with Windows, Linux, AIX three platform compilations, but there was a problem with Solaris, because there was a structure definition struct map in the header file if.h of the system, which conflicted with the module map in the C + + standard library, resulting in the inability to compile.

In this regard, the authors of boost are worthy of being experts in C + +, this is done well, and Ace is not too good, all identifiers are identified by prefix Ace_, guaranteed, and is uppercase, looks uncomfortable, if you want to use it can only endure, or write a separate header file, It is also a good idea to use a typedef or a macro definition to change the identifier, and then encapsulate the newly defined identifier into an ace command space.

5. Code comments

It's hard to remember the purpose of every piece of code. In particular, some special skills, must be readily written down, for their own maintenance or cooperation with colleagues are necessary, do not be afraid of others to understand their own code to their own threats, open some, only learn from each other to promote development, you put the code to others, Others will also give you advice to help you improve, China's first 100 years of history is a bitter lesson of complacency, the state, and individuals.

6. Version management tools

If several people maintain hundreds of thousands of lines of code without using a version management tool, you must have a feeling every day that you are wasting your life. Waste your own life is also to forget, if as a leader do not make a point of change, it is a waste of other people's lives, that is, murder.

7. Code specification

Everyone may have their own coding style, but the same project, should have only one style, otherwise may affect the work, although the program itself performance and function are not a problem, but the actual development of the product process will have an impact, because it will affect the mood of some thinking engineers, of course, will affect the efficiency, Because they always feel that the code is not standardized, the total want to modify these details, when the change may be replaced by another engineer to another style. So there must be a unified style to unify the behavior of each member of the team.

There is a detail, I still have experience. Some of the old code in the project is very messy, there is a function that can write hundreds of lines, and the braces {and} of the code block are all in a separate row, so that the full screen is curly braces and if-else, it looks like the code is not compact, such as: If-else
if (cond 1)
{
Line ...
Line ...
}
Else
{
Line ...
}
Change into
if (cond 1) {
Line ...
Line ...
}else{
Line ...
}

It looks a lot tighter.
There are a number of layers of code deep, a piece of code may have four-layer if conditions nested, it seems very laborious, if the condition of every decision to exit, the readability will be greatly improved, such as
if (cond 1) {
if (cond 2) {
if (cond 3) {
Work line
}
}
}
If you change to the following code, it will look more comfortable.
if (! Cond 1)
return–1;
if (! Cond 2)
Return–2;
if (!cond 3)
Return–3;
Work line

Of course written
if (cond 1 && cond 2 && cond 3) {
Work line
}
Better, but sometimes it's not so convenient.

8. Automated Construction

If a large project contains dozens of small modules, each time to manually compile dependencies, the efficiency is low, if you can automatically build the necessary modules will greatly improve work efficiency, even if you can enter a few characters is necessary.
For example, if one of our projects needs to run on Windows, Linux, AIX, HPUX, Solaris Five platforms, it is not convenient to execute configure before each compilation, and then execute make. If the public part is written in a makefile.comm, then write a makfile.win,makefile.linux for each platform dependency, Makefile.aix,makefile.hpux, Makefile.solaris, so you only need to input make–f each time Makefile.os to compile, but this is going to be a lot of input, you can build a Makefile file, and then automatically detect the system platform, and then call the corresponding Makefile, and then only need to enter make on the line, and then think simple, you can write a small script, file name M, which calls the made instruction, so that each time only You need to enter./m, and if you have too many characters to input, you can add it to your PATH variable and then directly enter M. If you want to be simple. That can only use special powers, play telepathy, I really do not think of other ways.
It's just an example. There may be more work to be done in the actual development process, but when you find that you are not the first to do something, you can consider how it will be simplified in the next encounter, which is the dry (Don t Repeat yourself) rule mentioned in the "procedure of Practice".

9. Automated Testing

For a large project, the amount of manual testing performed after each build is significant. If the company does not have a research and development team equipped with testers, and the test department can not be tested in time, research and development will be a lot of human waste in the test, so building their own automated test system is a vital element.

Talk about here for a moment, think again, have the opportunity to discuss with the Netizen, everybody good night.