Re: slightly OT: error handling conventions

From: The Real OS/2 Guy (os2guy_at_pc-rosenau.de)
Date: 10/22/03 

Date: Wed, 22 Oct 2003 11:09:48 +0000 (UTC)

On Wed, 22 Oct 2003 07:06:27 UTC, Christian Bau
<christian.bau@cbau.freeserve.co.uk> wrote:

some non-transparent code.

I've learned in my first days of programming (the dark age where not
even assembly was available) that

- making a well design is more than the half work.
- goto is evil and should be avoided whenever possible
  (o.k., in very low language as mashine code
  or assembly it is truly impossible but for that
  you can always design the code so that there is no
  long goto.
  And with C you can design the code always in a
  manner that NO goto is needed. Make the design
  right and you gets always transparent code.
- find a time inexpensive algoritm before you starts coding
  to reduce runtime when a loop tends to be time expansive
  That means: start to optimise time before the first statement
  gets written.

Good design in programming level is:

- a function has only one return in either success or fail
  The same function can have many return in the contrary case.
  That means: when the natural result of a function is FAIL
  then only ONE exit that flags the fail exist, but multiple
  returns flagging success may exist anyway.
  When the natural meaning of a function is success then only
  ONE return that flags the success exist, but multiple
  return flagging an error can exist.
- document each function well. This is needed for maintenance anyway,
  even when you are the only for eternity who will own the source.
  This will save you moth of maintenance.
  document the interface of each funtion well. This will
  save you time in using it.
- a fuction exeeding substantial more than one screen page
  is buggy per design.
- nesting more than 3 blocks (conditional, loops) tends to be
errornous
  break them down in nested fuctions increases the readability.
- breaking nested loops into nested functions helps in readability
  because a return error/successcode says more than a goto can ever
say.
- whenever your compiler is unable to support _inline_ use the
  preprocessor to define micro steps who are in themself not clearly
  writeable, because a self speaking function/macro name tells more
  than a non-transparent statement ever can. This increases the
  maintenanceability significantly.
- define macros who are object of changeability globally
- define macros you creates only for increasing the readability of
  code near the place(s) you need them. Don't forged to #undef them.
- avoid casting. Recheck the design before you tries to cast!
  cast only when you absolutely and exactly knows what you are doing,
  cast never only to get the comiler quiet without knowing
  exactly why it whines and you're not 100% sure that you knows what
  you're doing is better than the comiler knows. Be sure, commonly
  the compiler knows better than you why it is crying.

Whenever a fuction tends to be bigger than a screen page (about 50
lines), break it down in multiple functions:
- describe WHAT is to do in higher level and HOW is it done in lower
level
- break WHAT is to do from overview to more detailed.
- break HOW is to do to WHAT is to do until you gets fine details
- break HOW is to do in more fine details
- don't nest loops with conditions inside - make own functions out of
them.
  This increases the readability and makes it easier to debug
Whereas details means ownstanding functions. It is noways a disgrace
to write a function that gets called once. Because that function helps
you to write readable, clean code as it hides details in the flow and
tells by its name what is to be done.

A side effect of the above would be that you avoids goto, increases
the readability and maintenanceability significantly.

Again: prefere design over coding! Code only when the design is
crlean, checked and rechecked.

At compile time use the most detailed warning level - always! Because
the compier knows more about C as you'll ever be learn when you're not
a compiler developer. Letz the compiler help you to find unsave,
unsecure, unstable code! Again: never suppress a warning by casting
except you have checked and rechecked that you exactly knows that you
knows that the compiler can't know something you knows and you knows
here that even as the compiler means you may loose some data you knows
that it is impossible because you knows the min/max occures here fits. 

-- 
Tschau/Bye
Herbert
eComStation 1.1 Deutsch wird jetzt ausgeliefert!

Relevant Pages

  • Re: regarding "goto" in C
    ... That will increase the readability and security by hiding details while increasing the maintenceability and decreasing the time needed to debug the functionality. ... we have avoided the evil goto. ... I can't come up with arguments as to why a version that uses a control variable should be better design than one without it. ...
    (comp.lang.c)
  • Re: Prime Numbers Algorithms
    ... and because goto is a sanctioned C language construction ... > static unsigned int gcd(unsigned int a, ... the compiler will have a heck of a time folding together any branches. ... and no impact on the readability or simplicity in proving correctness. ...
    (comp.programming)
  • Re: when GOTO makes sense.
    ... >>code hoping to learn a good way to use goto for readability. ... but you still can trust the compiler farther ... everywhere that needs it right before the goto (a very poor solution), ...
    (comp.lang.c)
  • Re: regarding "goto" in C
    ... That will increase the readability and security by hiding details while increasing the maintenceability and decreasing the time needed to debug the functionality. ... I can't come up with arguments as to why a version that uses a control variable should be better design than one without it. ... This example in particular boils down to whether you think goto is bad or not. ...
    (comp.lang.c)
  • Re: why still use C?
    ... OOP in general tends to be slower. ... As if the compiler didn't know... ... > their associated method functions from a design perspective. ... as a language design I feel it has failed. ...
    (comp.lang.c)