Rod said:
There are two assumptions made in that statement:
1) that someone can always determine a method to solve every problem
2) that someone can always write a program which implements a solution
without errors
I'd start by learning how to solve some problems and write some programs
well. After solving and implementing
a few problems, you'll know whether you are better at "top-down" or
"bottoms-up" design. Each person has a
biological preference for each one (FYI, those who prefer "top-down" are N,
and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).
Hmmm, and what am I if I prefer one approach for some kinds of problems
and the other for other kinds of problems and the
midlevel-to-up-and-down and the come-from-top-and-bottom for yet
other classes of problems?
The following are my opinions for the C language are really are _specific_
to _my_ programming style. Others may not
have problems with the same areas of C that I do, so they probably have
their own list of issues. You'll need to develop
your own list of "problem areas" over time:
1) learn hexadecimal and the bit patterns for each value
2) don't forget your algebra
3) understand binary operations bitshifts, and, or, xor, one and two's
complement, etc...
If you need them, learn something about floating point numbers
and their shortcomings so you are not in for nasty surprises.
4) use #define masks to extract bits from variables instead of using unions
and use functions to wrap the semantics whenever the bit thing
is only an implementation decision...
5) include all the necessary include files, especially stdio.h and stdlib.h
6) avoid the use casts, except to ensure the type and precision of numerical
conversions and where you know it is necessary
7) avoid the use of type qualifiers (const, volatile, restrict), except
where necessary, because they can hide programming errors
How can const lead to errors unless you violate (6)?
8) avoid the use malloc(), except for dynamic data, because it leads to
memory allocation errors
.... it _can_ lead ...
8A) corollary: avoid the use pointers in main(), for the same reason
Avoid implementing any functionality in main(); main() essentially
just should call functions and assign to temps...
This step usually makes it easier to structure the program and the
tasks.
9) typedef structs and give them file scope (i.e., "global"), it can simply
certain problems
Are you talking about the type definition or about the instance?
@OP: As Rod said, everyone has their own list.
A look at a good textbook and the C FAQ before you start out
implementing something may make you aware of potential problems.
A couple of things which are not strictly C which I would add:
i) Use your compiler in the strictest possible mode, i.e.
a) use only standard C if you can get away with it
b) turn the warning level to maximum
ii) If sensible, use a lint-tool.
iii) If you get warnings or error messages, understand them. Do
not try to make them "go away" with tricks but by making sure
the (potential) problem they point out does not occur or by
changing the code so the problem cannot occur.
If you decide that the warning is not critical and your compiler
offers a #pragma to switch off a warning for a code section,
then switch it off for the smallest possible code section and
write a comment explaining why you switched it off.
iv) If you get beyond one file or beyond a thousand lines of code
or if you know beforehand that you might, then _plan_ahead_:
a) Use make or similar tools to automate the build process
b) Test every function or at least every module thoroughly and
separately -- it is much easier to find bugs this way.
If you design the test before writing the code, this may even
save you some time because you know which pitfalls to avoid.
c) Make tests that test the interaction of different software
components/modules/functions.
v) Do never ever take shortcuts in order to "optimise".
If your code is too slow and you have found out by measuring
which part it is that slows you down, then think about a better
way of implementing it. Keep the slow function/group of functions
so that you test whether the optimised code does the same. And
measure whether the optimised part is actually faster/more memory
efficient.
Cheers
Michael