02-01-2005, 08:34 PM
To: Laurent Perron,
I read with interest your question about combining #define symbols inside of #include statements. I agree with all of the comments by Walter Schilling in his reply to your post.
I would also like to add some additional comments of my own.
It has been my experience that during the evolution of a long duration project, it is often necessary to reorganize directory structures and/or physical locations of source files. It is extremely counterproductive if these sorts of administrative tasks impact the actual content of source files.
For managing includes, I have adotped a coding style that follows these four rules:
(1) Never use the form #include \"...\"
(2) Always use the form #include
(3) Only specify the exact filename inside of and DO NOT include any directory information whatsoever.
(4) Allow the compiler tools and/or operating system environment to resolve the included filename outside of the scope of the source code.
These rules accomplish the following:
(a) Files can be relocated and directories can be restructured without having to modify source code. This is particularly important when source code has been subjected to peer review and then archived in a version control system. Having to re-review and re-archive source files that have changed for trivial reasons is a monunmental waste of time.
(b) Portability is increased by keeping operating system dependencies in the specification of directory paths (and so forth) out of the source code. For example, a relative path such as ../thisstuff/thisfile will be correct in a UNIX or LINUX environment but incorrect in a Windows environment.
© Resolution of include file locations can be performed using directory search lists maintained by your local compiler, or even by symbolic references if your operating system supports this (UNIX/LINUX). This centralizes information about locations of files in one place instead of having references scattered throughout the source code files themselves.
I am interested in any comments that other developers might have with regard to the MISRA-C:2004 compilance (or non-compliance) of this approach to managing source file name resolution.
Best Regards,
-Jack D. Calderon
Heptagonal Technology
I read with interest your question about combining #define symbols inside of #include statements. I agree with all of the comments by Walter Schilling in his reply to your post.
I would also like to add some additional comments of my own.
It has been my experience that during the evolution of a long duration project, it is often necessary to reorganize directory structures and/or physical locations of source files. It is extremely counterproductive if these sorts of administrative tasks impact the actual content of source files.
For managing includes, I have adotped a coding style that follows these four rules:
(1) Never use the form #include \"...\"
(2) Always use the form #include
(3) Only specify the exact filename inside of and DO NOT include any directory information whatsoever.
(4) Allow the compiler tools and/or operating system environment to resolve the included filename outside of the scope of the source code.
These rules accomplish the following:
(a) Files can be relocated and directories can be restructured without having to modify source code. This is particularly important when source code has been subjected to peer review and then archived in a version control system. Having to re-review and re-archive source files that have changed for trivial reasons is a monunmental waste of time.
(b) Portability is increased by keeping operating system dependencies in the specification of directory paths (and so forth) out of the source code. For example, a relative path such as ../thisstuff/thisfile will be correct in a UNIX or LINUX environment but incorrect in a Windows environment.
© Resolution of include file locations can be performed using directory search lists maintained by your local compiler, or even by symbolic references if your operating system supports this (UNIX/LINUX). This centralizes information about locations of files in one place instead of having references scattered throughout the source code files themselves.
I am interested in any comments that other developers might have with regard to the MISRA-C:2004 compilance (or non-compliance) of this approach to managing source file name resolution.
Best Regards,
-Jack D. Calderon
Heptagonal Technology