Re: give me some tips

Rod Pemberton schrieb:
"Yuri CHUANG" <yuri_1985@xxxxxxx> wrote in message
news:1142143263.604302.218540@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

So I desire to know some tips about writting a program perfectly.

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?

Can
anyone give me some tips which are hardly learned from textbook or
easily ignored?

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
.

Relevant Pages

  • [PATCH] input: Silence unused variable warning in iforce joystick driver
    ... The warning is easy to avoid by simply moving the variable inside ... the only case in the switch that actually use it. ...
    (Linux-Kernel)
  • Re: Cant switch to virtual console anymore
    ... > I can't switch to a virtual console any longer. ... > happened must have happened during my last "aptitude upgrade", ... that line always caused a benign warning. ...
    (Debian-User)
  • Re: dereferencing type-punned pointer will break strict-aliasing rules
    ... our warning flags are missing other new gcc warnings. ... object code size (the memcpy gets optimized away in almost the same way ... The temporary variable with a basic type is to avoid gcc getting confused ... There is no problem loading the source operand since only its address ...
    (freebsd-current)
  • Re: 3 year old "defiant" behaviour
    ... turning the light switch on and off rapidly. ... > ds: no response, continues behavior ... > DS, this is your warning. ... Warnings are great when it comes to letting a kid know that the time ...
    (misc.kids)
  • Re: problem with macros
    ... Agree with you about the switch case. ... double *vector_iterator(vector *v, int axis) ... I actually got this warning in many other programs when there was no ... When control reaches the terminating brace of a non-void function then ...
    (comp.lang.c)