How to program in C

    "If it weren't for C, we'd be writing programs in BASI, PASAL, and OBOL."

   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.
   7. Rewrite standard functions and give them your own obscure names.
   8. Use obscure, proprietary, non-portable, compiled library packages so that you never have to move from the platform you love so well.
   9. Use very descriptive comments like /* printf("Hello world\n"); */ before each function call.
  10. REMEMBER - Carriage returns are for weenies. Tabs are for those who have not reached weenie-dom yet.
  11. Include LOTS of inline assembly code.
  12. "User Interfaces" are for morons. "Users" have no business interfacing with a professional product like yours.
  13. 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.
  14. Remember to define as many pre-processor symbols as possible in terms of already defined symbols. This is considered 'efficient use of code'.

You'll need GCC to program in C.
 If you can't ftp, you can order a compiler beta-test tape from the
   Free Software Foundation for $150 (plus 5% sales tax in
   Massachusetts, or plus $15 overseas if you want air mail).

   Free Software Foundation
   1000 Mass Ave
   Cambridge, MA  02138

1. Use fprintf ("fast printf") instead of printf.
2. ++i is faster than both i++ and i = i + 1.
3. void main(void) is faster than int main(void) or int main(int, char **) since no value needs to be returned to the OS.
4. Swapping with exclusive-or (a^=b^=a^=b swaps a and b) is faster than using a temporary. This works for all types (including structures), but not on all compilers. Some compilers may also give you a harmless warning.
5. Static storage duration objects are faster than automatic storage duration objects because the CPU doesn't have to set aside storage on the stack every time a function is called. Make your loop indexes global so that you can use them everywhere:
int i;
void func(void) { for (i = 0; i < 10; i++) ; /* ... */ }
void func2(void) { for (i = 0; i < 20; i++) ; /* ... */ }
/* ... */
6. Compilers often give more memory to arrays than you asked for. Here's how to check how big an array actually is (memset returns a null pointer if the size you passed to it is bigger than the size of the array you passed to it):
int arr[256];
size_t realsize;
for (realsize = 0; realsize <= SIZE_MAX; ++realsize)
        if (!memset(arr, 0, realsize)) break;
/* now you know that arr actually has realsize / sizeof (int) elements */
If you combine this with #5, your program will be faster in the long run (but this usually doesn't work for short programs).

>>3
1. True, although it's not actually "fast printf".
2. False.
3. False.
4. False.
5. Depends, usually false.
6. IHBT

>>4 is an attempt at meta-trolling

>>1
I'd like to address this.
1. Use lots of global variables.
Actually, I do use global variables, as a replacement for a suitable runtime environment, which C lacks. The existence of global variables is exactly the kind of things I've abstracted, for which C cannot handle at runtime.

2. Give them cryptic names such as: X27, a_gcl, or Horace.
Well, I don't know if they're cryptic or not. Read my literate programming document of the software and let me know if they are still incomprehensible.

3. Put everything in one large .h file.
Oh, are you very sad that C has no modularity built in to the language? Me too. It's why I avoid C whenever practical.

4. Implement the entire project at once.
Oh, how cute. A programmer who feels it necessary---simultaneously---to work at a low level (C) and abstract enough to have independence. Well, I am impressed at your cognitive dissonance, does that make you feel better?

7. Rewrite standard functions and give them your own obscure names.
Aww, did specializing functions in a specific environment hurt you personally? NULL NULL NULL NULL 3

8. Use obscure, proprietary, non-portable, compiled library packages so that you never have to move from the platform you love so well.
You're right, I should program my ZiLOG XP Encore microcontroller like it is an X86_64 processor!

9. Use very descriptive comments like /* printf("Hello world\n"); */ before each function call.
Too bad your pet language practically demands printf debugging because it has no reflection.

Yes, yes, IHBT.

>>6
You are probably the worst troll to have ever walked /prog/.

>>1
FrozenVoid actually codes like this.

This reminded me of the first time I had a look at the Build Engine source code, the game engine behind Duke Nukem 3D.

The first thing that you notice once you unzip src.zip is that there is a rather small number of source files in the system, rather strange compared to modern game engines.

And then you notice the size of the files in kilobytes, or should I say hundreds of kilobytes.

And this was just the beginning. If you're curious, you can have a look yourselves by downloading it here: http://www.advsys.net/ken/buildsrc/kenbuild.zip

>>6
You haven't been trolled, you have been an idiot. OP was never meant to be taken seriously.

>>9
Not only that, the code is written for a tab size of 3.

>>11
That's as bad as trying to program on a machine with 6-bit bytes.

>>12
There is worse. One of those 6 bits is reserved for garbage collection purposes.

>>13
On my system it is the third least significant bit. :(

15 MY ANUS

4. Implement the entire project at once.
What the bloody fuck is that supposed to mean?

>>16

It involves square time

>>16
If you don't know, then you're not a real programmer

FOLLOW THE NEW GNAA TWITTER AT http://twitter.com/Gary_Niger

Newer Posts

---

Don't change these.

Name:		Email:
Entire Thread Thread List