Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Good Programming stops guru |||| and BNF of C++ Message-ID: Date: 14 Jan 91 02:17:05 GMT References: <4381@mindlink.UUCP> <8bXHP_y00VIFALti1O@andrew.cmu.edu> Organization: Not an Organization Lines: 63 In article <8bXHP_y00VIFALti1O@andrew.cmu.edu> rg20+@andrew.cmu.edu (Rick Francis Golembiewski) writes: > >Also watch when passing constant arguments, for instance calling: >foo(A,B,0,D) >for >int foo(A,B,C,D) >double A,B,C,D; >{ >} >is wrong, it should be >foo(A,B,0.0,D) > ^ > | > This a a FP argument while 0 is interpreted as an integer argument, This is one of things that prototypes will do for you... argument converesion. If you had the prototype: int foo(double, double, double, double); then foo(A,B,0,D); will work just fine. >In general it's a good idea to initiallize ALL of your variables, as >some compilers initalize vars to 0 while others may not. Not true, you can rely on static's and global's being initialized to 0, assuming you go through the normal startup obj for the compiler. auto's (stack variables) are NOT initialized (i.e. contain garbage until you initialize them) >Try not to have lots of global variables, but if a variable gets >passed to most every function it is probabily a good idea to make it >globa (things like window & screen pointers are things that come to >mind). Try to break down your code into small modules so that they are >easier to debug, (and so that the smaller lower level modules may be >used in other programs without rewriting them). Don't make >allocations (of memory, or any ofther resource ie [ports, audio >chanels]) unless you need them, adnd then FREE THEM UP WHEN YOU ARE >DONE! (ie fclose(file), free(memory) etc.). There are certainly >several other good programming practices, but I think that this post >is long enough already. I'm sure that if I've made any mistakes in >the above I'll get plenty of flames for it... Those are good points. The term you are looking for 'Modularity'. I have found that by dividing procedures in a logical manner and not using globals for variables that really ought to be locals (like a loop counter) you generally wind up with much better code no matter what kind of programmer you are. >// Rick Golembiewski rg20+@andrew.cmu.edu \\ >\\ #include stddisclaimer.h // > \\ "I never respected a man who could spell" // > \\ -M. Twain // -- -Matt Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA