15 Good Programming Habits

1. Before sitting down for coding, you must have formal or a paper-napkin design of the solution to be coded. Never start coding without any design unless the code is trivial one.

2. Good code documentation is as important as good knowledge of a programming language. Write brief logic for each major block of your code as comments in source code file itself. Its good to mention creation and modification dates of your program along-with why modification was required.

3. Maintaining versions of your program is another important task. Some present-day programming tools already have a built-in version management. Whenever you make any change to your program, they save its copy as.bak file.

My approach is to maintain 3 versions of a program. Say, I have a file program.c which is used by other project team members also. I copy this file as program.c.old as backup and make another copy as program.c.wrk where I do modifications. When modifications are successfully compiled, replace program.c with.wrk file.

You can also append a date or some explanation phrase to your program versions like program260505.c or programReadFnWrking.c.

4. If your project contains multiple source files then maintain a README file stating purpose of each source files, data files, intermediate and log files (if any). You may also mention the compilation and execution steps.

5. Ever wondered why your IF statement is not working as it should do. May be your are using single equal i.e. "=" instead of "==" in the condition check. A good approach is to write condition in reverse order. So, your condition should read something like this:

if ( 10==i).... So, if you put single equal sign by mistake then it will be detected at compilation time only as an error.

6. While using loops and conditional statements, always first put closing braces corresponding opening braces and then write the inner statements i.e.
Note: This applies only to C series fags ^^.
1) for(int i=0;i<10;i++)

2) {

4) printf("i=%dn",i);

3) }

The numbers at the starting of each line indicate sequence of writing loop code.

7. Avoid using magic numbers. For example, instead of writing

circleArea = 3.14 * pow(radius,2)

Use following code:

#define PI 3.14
circleArea = PI * pow(radius,2)

VB Equivalent:
Const PI = 3.14
circleArea = PI * pow(radius,2)

8. Use meaningful variable and function names. For e.g. instead of using 'r' use 'radius' to represent radius of a circle. Similarly, function name 'calculateArea' is better than any cryptic short name. In a hurry, we may use short variable names but the time saved leads to double wastage of time later when you guess for what that short variable name stands for.

9. Using print statements for later debugging is a good habit. But, removing them when final code is ready is, sometimes, a risky task. So, make a function that displays debugging information passed to it. When your final version is ready, simply comment the internals of this function. So, this requires changes only at one place.

10. Once you are done with coding, start optimizing your code. Some of the variables you declared earlier may not be of use at this stage. Similarly, statements which are not loop dependent can be moved out of loop block. Sound knowledge of compiler can also help in optimizing the code further.

11. With good knowledge of your operating system and hardware, you can improve performance of your program in terms of resource requirements etc.

12. Always indent your code for clarity and easy readability.

13. You will also like the idea of organizing project files in into various folders like SOURCE, HEADERS, MAKE, EXES etc.

14. Study the code written by others. This will bring to you new programming techniques and what approach they have followed for the task for which you have also coded. (You Sir, sound leecher to me...LOL)

15. Last but not least important, take backup of your source-code files so that your effort don't go waste if hard-disk crashes or a similar mis-happening occurs.

Written By: Al-Katib (Some guy on internet) !!

Felt like sharing it. Enjoy ^^

I disagree with quite a bit of this =\
*too lazy to expand*

1. Only needed if you have alzheimer and keep on forgetting what it was you were trying to code...

2. Only required when working in a team and your teammates are too fucking stupid to grasp the idea behind a "bool isOnScreen(int playerID)" means.

3. Only for noobs who fuck up their program by overwriting it's content...

4. Again, only if your team is full of retards. 'I wonder what CPlayer.cpp contains'

5. Might be time to buy glasses.

6. It's called indenting your code, read up on it.

7. First useful point...

8. How can you possibly forget what your variables do unless they're global and have bullcrap names...

9.
#ifdef debugging
print
#endif
Know about it...

10. Pro tip: only declare variables when you need them. saves you some hassle removing unused ones.

11. Just load your resource when you need em, instead of in a gigantic loop that makes no fucking sense.

12. Should be higher on the list...

13. Why? just organize them in your IDE...

14. Leeching fag(agree with op)

15. Best idea ever.

Shit daum, get raped son.

Lawl... Nice .... I myself disagree with some points, but some are good too...but too lazy to follow. I think I write the roughest code among all of us ! xD

Are you freaking serious? O:

Some of those are bad things :L

not necessarily bad... just.. useless... you won't be bad for using them.

Good practice.
Who says you'll only ever work by yourself?
Also, a readme is for distributing your work - doesn't matter who you work with.
Always good to have skills like good commenting, good API usage, nice deployment, good documentation, even UML diagrams. It just helps.