Name: Anonymous 2007-04-14 5:24 ID:OOhfheQR
How to program in "C"
1] Use lots of global variables.
2] Give them cryptic names such as: X27, a_gcl, or Horace.
3] Put everything in one large .h file.
4] Implement the entire project at once.
5] Use macros and #defines to emulate Pascal.
6] Assume the compiler takes care of all the little details you didn't quite understand.
"It's 5:50 a.m., Do you know where your stack pointer is?"
[ No, and my program doesn't, either! ]
How to debug a "C" program.
1] If at all possible, don't. Let someone else do it.
2] Change majors.
3] Insert/remove blank lines at random spots, re-compile, and excecute.
4] Throw holy water on the terminal.
5] Dial 911 and scream.
6] There is rumour that "printf" is useful, but this is probably unfounded.
7] Port everything to CP/M.
8] If it still doesn't work, re-write it in assembler. This won't fix the bug, but it will make sure no one else finds it and makes you look bad.
The recent submission of "How to program in C" left out some very important rules.
I have come up with the following list of additional rules in order to give the serious student some aid and the professional a refresher.
How to program in 'C' - addendum
1] Rewrite standard functions and give them your own obscure names.
2] Use obscure, proprietary, non-portable, compiled library packages so that you never have to move from the platform you love so well.
3] Use very descriptive comments like /* printf("Hello world\n"); */ before each function call.
4] REMEMBER - Carriage returns are for weenies. Tabs are for those who have not reached weenie-dom yet.
5] Include LOTS of inline assembly code.
6] "User Interfaces" are for morons. "Users" have no business interfacing with a professional product like yours.
7] If you are forced to comment your code (in English), then borrow comments from somebody else's code and sprinkle them throughout yours. It's quick, easy, and fun to watch people's expressions as they try to figure it out.
8] Remember to define as many pre-processor symbols as possible in terms of already defined symbols. This is considered 'efficient use of code'.
How to debug a 'C' program - addendum
1] Since you got it to compile, the problem must be in the Other Guys Code.
2] If it's all your code then the problem MUST be in those unreliable Standard Libraries. See '1.' in the previous section.
3] Claim the bug reports are viscious lies meant to tarnish your sterling reputation as a 'C' programmer (well aren't they?). After all, those who wrote the reports couldn't even read your code. How could they possibly know if there was a bug or not?
3.a] If they could read your code, review "How to program in 'C'", above.
4] Claim that there wouldn't be a problem if this stingy Company/School/Wife/etc would spring for a copy of C++.
1] Use lots of global variables.
2] Give them cryptic names such as: X27, a_gcl, or Horace.
3] Put everything in one large .h file.
4] Implement the entire project at once.
5] Use macros and #defines to emulate Pascal.
6] Assume the compiler takes care of all the little details you didn't quite understand.
"It's 5:50 a.m., Do you know where your stack pointer is?"
[ No, and my program doesn't, either! ]
How to debug a "C" program.
1] If at all possible, don't. Let someone else do it.
2] Change majors.
3] Insert/remove blank lines at random spots, re-compile, and excecute.
4] Throw holy water on the terminal.
5] Dial 911 and scream.
6] There is rumour that "printf" is useful, but this is probably unfounded.
7] Port everything to CP/M.
8] If it still doesn't work, re-write it in assembler. This won't fix the bug, but it will make sure no one else finds it and makes you look bad.
The recent submission of "How to program in C" left out some very important rules.
I have come up with the following list of additional rules in order to give the serious student some aid and the professional a refresher.
How to program in 'C' - addendum
1] Rewrite standard functions and give them your own obscure names.
2] Use obscure, proprietary, non-portable, compiled library packages so that you never have to move from the platform you love so well.
3] Use very descriptive comments like /* printf("Hello world\n"); */ before each function call.
4] REMEMBER - Carriage returns are for weenies. Tabs are for those who have not reached weenie-dom yet.
5] Include LOTS of inline assembly code.
6] "User Interfaces" are for morons. "Users" have no business interfacing with a professional product like yours.
7] If you are forced to comment your code (in English), then borrow comments from somebody else's code and sprinkle them throughout yours. It's quick, easy, and fun to watch people's expressions as they try to figure it out.
8] Remember to define as many pre-processor symbols as possible in terms of already defined symbols. This is considered 'efficient use of code'.
How to debug a 'C' program - addendum
1] Since you got it to compile, the problem must be in the Other Guys Code.
2] If it's all your code then the problem MUST be in those unreliable Standard Libraries. See '1.' in the previous section.
3] Claim the bug reports are viscious lies meant to tarnish your sterling reputation as a 'C' programmer (well aren't they?). After all, those who wrote the reports couldn't even read your code. How could they possibly know if there was a bug or not?
3.a] If they could read your code, review "How to program in 'C'", above.
4] Claim that there wouldn't be a problem if this stingy Company/School/Wife/etc would spring for a copy of C++.