How to be a better programmer

bydand

Senior Master
Joined
Feb 6, 2006
Messages
3,723
Reaction score
32
Location
West Michigan
Want to be a good programmer ? If so, follow these programming practices and guidelines:

1) Never write a line of code that someone else can understand.

2) Make the simplest line of code appear complex. Use long counter intuitive names.
Don't ever code "a=b", rather do something like this :
AlphaNodeSemaphore=*(int)(&(unsigned long)(BetaFrameNodeFarm));

3) Type fast, think slow.

4) Never use direct references to anything ever.
Bury everything in macros.
Bury the macros in include files.
Reference those include files indirectly from other include files.
Use macros to reference those include files.

5) Never include a comment that will help someone else understand your code.
If they understand it, they don't need you.

6) Never generate new sources. Always ifdef the old ones. Every binary in the world should be generated from the same sources.

7) Never archive all the sources necessary to build a binary. Always hide on our own disk. If they can build your binary, they don't need you.

8) Never code a function to return a value. All functions must return a pointer to a structure which contains a pointer to a value.

9) Never discuss things in concrete terms. Always speak in abstract. If they can understand you, they don't need you.

10) Never complete a project on time. If you do, they will think it was easy and anyone can do it and they don't need you.

11) When someone stops by your office to ask a question, talk forever, but don't answer the question. If they get their questions answered, they don't need you.

12) Load all sentences either written or spoken with alphabet soup. When someone asks you out to lunch, reply:
"I can't because I've almost got my RISC-based OSI/TCP/IP client connected by BIBUS VMS VAX using SMTP over TCP sending SNMP inquiry results to be encapsulated in UDP packets for transmission to a SUN 4/280 NFS 4.3 BSD with release 3.6 of RPC/XDR supporting our ONC effort working."

13) Never clean your office. Absolutely never throw away an old listing.

14) Never say hello to someone in the hallway. Absolutely never address someone by name. If you must address someone by name, mumble or use the wrong name.
Always maintain the mystique of being spaced out from concentrating on complex logic.

15) Never wear a shirt that matches your pants. Wear a wrinkled shirt whenever possible.
Your shirt must never be tucked in completely. Button the top button without wearing a tie. This will maximize your mystique.
 

4) Never use direct references to anything ever.
Bury everything in macros.
Bury the macros in include files.
Reference those include files indirectly from other include files.
Use macros to reference those include files.


I've spent way too much of my life reading code written like that...
 
ur describing the programmer 5 people worked so hard for 6 months to fix his code! it's still not fixed
 
Want to be a good programmer ? If so, follow these programming practices and guidelines:

1) Never write a line of code that someone else can understand.

2) Make the simplest line of code appear complex. Use long counter intuitive names.
Don't ever code "a=b", rather do something like this :
AlphaNodeSemaphore=*(int)(&(unsigned long)(BetaFrameNodeFarm));

3) Type fast, think slow.

4) Never use direct references to anything ever.
Bury everything in macros.
Bury the macros in include files.
Reference those include files indirectly from other include files.
Use macros to reference those include files.

5) Never include a comment that will help someone else understand your code.
If they understand it, they don't need you.

6) Never generate new sources. Always ifdef the old ones. Every binary in the world should be generated from the same sources.

7) Never archive all the sources necessary to build a binary. Always hide on our own disk. If they can build your binary, they don't need you.

8) Never code a function to return a value. All functions must return a pointer to a structure which contains a pointer to a value.

9) Never discuss things in concrete terms. Always speak in abstract. If they can understand you, they don't need you.

10) Never complete a project on time. If you do, they will think it was easy and anyone can do it and they don't need you.

11) When someone stops by your office to ask a question, talk forever, but don't answer the question. If they get their questions answered, they don't need you.

12) Load all sentences either written or spoken with alphabet soup. When someone asks you out to lunch, reply:
"I can't because I've almost got my RISC-based OSI/TCP/IP client connected by BIBUS VMS VAX using SMTP over TCP sending SNMP inquiry results to be encapsulated in UDP packets for transmission to a SUN 4/280 NFS 4.3 BSD with release 3.6 of RPC/XDR supporting our ONC effort working."

13) Never clean your office. Absolutely never throw away an old listing.

14) Never say hello to someone in the hallway. Absolutely never address someone by name. If you must address someone by name, mumble or use the wrong name.
Always maintain the mystique of being spaced out from concentrating on complex logic.

15) Never wear a shirt that matches your pants. Wear a wrinkled shirt whenever possible.
Your shirt must never be tucked in completely. Button the top button without wearing a tie. This will maximize your mystique.

In other words, program in C++! :D
 
In other words, program in C++! :D

Nah... try some things w/ SED. Or get really cryptic w/ Assembly. I really enjoyed learning that :)

1) Never write a line of code that someone else can understand.
 
Or get really cryptic w/ Assembly. I really enjoyed learning that :)

1) Never write a line of code that someone else can understand.

C++ can get mightily opaque... but yeah, Assembly, that's just not an Earthling language! When did you have to program in Assembly... and who was the sadist who made you do that??
 
I went from Atari BASIC to 6502 Assembler. Now I do mostly Smalltalk with some Java and some hobbying around with C, Python, and whatever else I need to.

Most annoying and incomprehenisble to read languages: Perl and TCL
 
C++ can get mightily opaque... but yeah, Assembly, that's just not an Earthling language! When did you have to program in Assembly... and who was the sadist who made you do that??

LOL

I took it for a computer science minor in college. I actually enjoyed it! I got to be friends with the teacher. He let me design a project for the class. We wrote a few cool viruses :) nothing harmful, but it was sure fun!
 
How about letting your three old do the progamming since he is smarter than me ith it anyway
 
I went from Atari BASIC to 6502 Assembler. Now I do mostly Smalltalk with some Java and some hobbying around with C, Python, and whatever else I need to.

Most annoying and incomprehenisble to read languages: Perl and TCL

Over the past few years almost all I do is Perl and shell scripting. I need to pick up Java one of these days...
 
Figured some of you could relate to this. I found it while stumbling about the net and had to post it. Personally I know almost nothing about programming. :)
 
LOL

I took it for a computer science minor in college. I actually enjoyed it! I got to be friends with the teacher. He let me design a project for the class. We wrote a few cool viruses :) nothing harmful, but it was sure fun!

The thing with Assembly-level languages is, if you try explaining what they are to the current 16 year old database builders programming stuff in Perl (or the AI types writing stuff up in Prolog) they probably will have no clue---none, zip---what you're talking about. Every Lisp or Prolog command corresponds to an assembly level macro the size of a small book... assembly makes these high-level languages look practically wysiwyg... you say this was fun??
:D
 
The thing with Assembly-level languages is, if you try explaining what they are to the current 16 year old database builders programming stuff in Perl (or the AI types writing stuff up in Prolog) they probably will have no clue---none, zip---what you're talking about. Every Lisp or Prolog command corresponds to an assembly level macro the size of a small book... assembly makes these high-level languages look practically wysiwyg... you say this was fun??
:D

Its control man! You don't have some unknown performing functions for you. YOU are the one flipping bits, pushing things into registers, all that jazz...

the problem is it takes about 5 years to program your computer to print "hello world". Also, if you don't know what you are doing, you can mess things up pretty easy...

I also enjoy trying to figure out the logic of things. exactly -how- do you print "hello world".... with higher level languages its kind of trivial.
 
The thing with Assembly-level languages is, if you try explaining what they are to the current 16 year old database builders programming stuff in Perl (or the AI types writing stuff up in Prolog) they probably will have no clue---none, zip---what you're talking about. Every Lisp or Prolog command corresponds to an assembly level macro the size of a small book... assembly makes these high-level languages look practically wysiwyg... you say this was fun??
:D


No pops, stacks, or registers for me! :eek: I looked at it once and decided it was way to tedious and took too long to get things done.

I prefer Visual Studios .NET either VB.NET, ASP.NET, or C#. C++ takes too long now to roll out an app.
 
Yeah really! Build middle teir objects in C++ and have all your VB and ASP use it. They love that.

Don't forget to write that one crucial procedure, upon which all others depend, in ASM to be called by the C++ code. For "speed considerations". Yeah, that's it.
 
I once had to get 8 bytes to add in a "BEEP" sound feedback for a button for the Chrysler DRBIII tech tool. When I took over the code there was no room in the stand alone portion, and this request came in, and so I tried to find a way inbetween the C++ using OOD and classes, and the assembly generated.

I realized a couple of instructions with the classes were repeated at the end of a session but were proper coding techniques. So, I commented out the first two and got my 8 bytes and verified that the third line I modified worked just like the old implementation worked. I then wrote three full pages single space of comments to explain why I did it and how I did it, and why it works even though it looks like it should not.

I left the company for a permanent position at my current employer, and a couple of months after I left I got a call from the original guy who wrote the code, and he was first mad that I had messed up his OOD and hacked his code. He was also mad because before he left he told them that it was impossible to execute. He then told me he was impressed that I was able to find a way. :D
 
he was first mad that I had messed up his OOD and hacked his code. He was also mad because before he left he told them that it was impossible to execute. He then told me he was impressed that I was able to find a way. :D

I hope you reminded him that in the progamming world, there are no problems, only solutions! :D
 
Back
Top