User`s manual

110 digi.com Debugging with Dynamic C
• Coding Standards: The use of coding standards increases maintainability, portability and re-use of
code. In Dynamic C libraries and sample programs
i
some of the standards are as follows:
- Macros names are capitalized with an underscore separating words, e.g., MY_MACRO.
- Function names start with a lowercase letter with an underscore or a capital letter separating
words, e.g., my_function() or myFunction().
- Use parenthesis. Do not assume everyone has memorized the rules of precedence. E.g.,
y = a * b << c; // this is legal
y = (a * b) << c; // but this is more clear
- Use consistent indenting. This increases readability of the code. Look in the Editor tab in the
Environment Options dialog to turn on a feature that makes this automatic.
- Use block comments (/*...*/) only for multiple line comments on the global level and line
comments (//) inside functions, unless you really need to insert a long, multiple line comment.
The reason for this is it is difficult to temporarily comment out sections of code using /*...*/
when debugging if the section being commented out has block comments, since block com-
ments are not nestable.
- Use Dynamic C code templates to minimize syntax errors and some typos. Look in the Code
Templates tab in the Environment Options dialog to modify existing templates or create you
own. Right click in an editor window and select Insert Code Template from the popup menu.
This will bring up a scroll box containing all the available templates from which to choose.
• Syntax Highlighting: Many syntactic elements are visually enhanced with color or other text attributes
by default. These elements are user-configurable from the Syntax Colors tab of the Environment
Options dialog. This is more than mere lipstick. The visual representation of material can aid in or
detract from understanding it, especially when the material is complex.
• Revision Control System: If your company has a code revision control systems in place, use it. In addi-
tion, when in development or testing stages, keep a known good copy of your program close at hand.
That is, a compiles-and-runs-without-crashing copy of your program. Then if you make changes,
improvements or whatever and then can’t compile, you can go back to the known good copy.
6.5.2 Finding the Bug
When a program does not compile, or compiles, but when running behaves in unexpected ways, or perhaps
worse, runs and then crashes, what do you do?
Compilation failures are caused by syntax errors. The compiler will generate messages to help you fix the
problem. There may be a list of compiler error messages in the window that pops up. Fix the first one, then
recompile. The other compile errors may disappear if they were not true syntax errors, but just the com-
piler being confused from the first syntax error.
During development, verify code as you progress. Develop code one function at a time. Do not wait until
you are finished with your implementation before you attempt to compile and run it, unless it is a very
short application. After a program is compiled, other types of bugs have a chance to reveal themselves.
The rest of this section concentrates on how to find a bug.
i. Older libraries may not adhere strictly to these standards.