Open Watcom Developer's Guide - HEAnet Mirror Service
Open Watcom Developer's Guide - HEAnet Mirror Service
Open Watcom Developer's Guide - HEAnet Mirror Service
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Style<br />
• function declarations and global variable definitions<br />
• function implementation<br />
As you can see, nothing fancy. Many programmers prefer to order functions so as to<br />
minimize forward declarations, ie. a main() function would be located at the end and every<br />
function fully defined before it is first used.<br />
You can use extern declarations but you should be very careful. It is strongly encouraged that<br />
all declarations of external functions and variable be located in header files which are<br />
included in modules that use them as well as modules that define them. The reason is simple<br />
— this way the compiler will tell you if you change the definition but not the header file. If<br />
you use ad-hoc extern declarations, you better make sure they’re in sync with the actual<br />
definitions.<br />
7.2 Help the compiler and it will help you<br />
While the compiler is a rather sophisticated piece of software, it cannot divine your intentions.<br />
Hence you have to help it a bit by giving hints here and there. And if you help the compiler in<br />
this way, it will be better able to help you.<br />
First of all, always compile with maximum warning level. Just because a message is called a<br />
warning and not error doesn’t mean you can ignore it. In fact many projects treat warnings as<br />
errors and will not build if any warnings are present. That is a Good Thing.<br />
Use the static keyword often because it is good. This is a multi-faceted keyword and its exact<br />
semantics depend on where it is applied:<br />
globals<br />
locals<br />
here the static modifier does not change the storage class but makes the variables<br />
local to the module where they are defined, that is they won’t be visible from<br />
other modules. If a variable needs to be global but doesn’t have to be accessed<br />
from other modules, you should definitely make it static. That way you will not<br />
needlessly pollute the global namespace (reducing the chance of name clashes)<br />
and if you stop using the variable, the compiler will warn you. If you have a<br />
non-static global variable that is unused, the compiler cannot warn you as it has<br />
to assume that it is used from other modules.<br />
in this case the static keyword changes the storage class and the variable will be<br />
stored in data segment instead of on stack. If you need a variable that has global<br />
lifetime but only needs to be accessible from one function, making it local and<br />
static is a good choice.<br />
36 Help the compiler and it will help you