Good programming habits

[abdul]

I just want your opinion on some good programming habits. I have written two incomplete programming - about 5 pages each, and after some days, when I try to edit then again, it just looks really messy and I am confused with all those files and stuff.

I just want to that how do I organize my project so that it does not look so messy(EG: Putting the function, putting what kind of stuff in the header files, doing what kind of commenting).

[Dillinger4]

Never eat a peanut butter and jelly sandwich while programming, the jelly could drip out and get your keyboard all
sticky.

[abdul]

Originally posted by Dilenger4
Never eat a peanut butter and jelly sandwich while programming, the jelly could drip out and get your keyboard all
sticky.

Even if I eat jelly sandwich near a computer, I turn the monitor upside down, open up some *good looking* web sites, and eat that way so that it drips, it drips on the screen, and then...

Good suggestion Anybody else?

[Megatron]

Here are a few

1) Indent your code

void main() 
{
    int nVar;
    return 0;
}

2) Use C++ style comments all the time except for code intros and long explainations

/* This looks cryptic for a one liner */

// Even tought you have to type // for each line
// it still looks neater to organize your comments.
// It's a good idea to use C++ style comments for short
// paragraphs.

/*


            C Style comments can be used for long comments,
            e.g the intro to the source-code/program, or explaining
            things.

*/

3) Decide on a position for the braces and use that style throughout the program. Don't be switching back and fourth.

// Style 1
void func()
{
    // Body
}

// Style 2
void func() {
    // body
}

4) Don't use braces for one-liner if's and for's

if( condition )
   // do something

// avoid using the below unless you have more than 1 line
if(condition)
{
    // do something
}

5) Make use of white space, e.g:

int              myVar,       Var2,     nextVar;
char           *name,     *last,     *phone;
for( i=0;  i < 10;  i++ )

6) Try to get in the habit of using constants (even if they are long).

#define A_REALLY_LONG_CONSTANT_YOU_WANT_TO_AVOID_TYPING    0;

MyFunc( Param1, A_REALLY_LONG_CONSTANT_YOU_WANT_TO_AVOID_TYPING);

[abdul]

Thanks Megatron I will be now working on a chat program, and I will see how much I get can get along with this programming style

[jim mcnamara]

More than just that -

1. Use self-Documenting variable & function names, except for loop counters. --- char *buf, int i, and all that should be only for working variables.

2. Avoid trying to write elegant code, the compiler is smart enough to make good, tight machine language.
Elegant equals: terse, hard to read, many functions crammed into one statement.

3. Keep functions to the point. Don't try to have one function do 8 things. Any function longer than one page (about 50-80 lines)
becomes hard to read six months later. Dissect a function down to it's elements - for example - Trim is the same as calling Ltrim then Rtrim. Don't write a separate Trim function, use existing code. Reduces probability of bugs a lot. The only time this isn't true is writing gaming software where in-lining is a standard method to increase both speed and bugs.

4. Put all of your #define, #include and other directive statements at the very top of the file. Don't sprinkle them around.

[kedaman]

- Object Oriented Programming
Organisation
Start your project by declaring classes, base and sub classes so you can keep a organized structure and delegate functionality and responsibility to each and one of the classes, this goes as well for every independent function in your project.
Scoping, Encapsulation
Functions or classes that are not independent shouldn't either be exposed to any other parts to your project than from which they depend on. By restricting access to them, by using scoping, you avoid unnessesary exposure and by that possibilities for bugs and by that time to debug. As a rule, keep things as private as possible.
Constants
Another debugging horror is to find out bugs in all functions called within a statement or an algoritm in general, if you pass a pointer or a reference, you will never know what happens to it. By declaring Constant pointers, constant references you restrict the function from changing the parameters, by declaring constant methods you restrict the method from manipulating the member variables, which in turn enables you to use the method if the object is passed constant.
Black box analogy
Each class and function that is exposed to a certain scope should maintain the black box analogy, that is it is responsible of returning correct output for each possible input passed from its environment. Usually programmers won't take this too seriously, and it's usefulnes only shows as your project grows, but if you even plan to do something more advanced, start using this technique and you'll save tons of time on unnessesary debugging.
To maintain the black box analogy, you use error handlilng, you trap all false input and return error codes, use try-catch statements or assertions to effectively get rid of the most common invalid inputs. When calling functions that give feedback on error codes, you should handle them as well as soon as possible, in case you're using try-catch which i personaly don't like.

[parksie]

Also, make good use of the standard library. I know this comes under reusing existing code, but it is definitely worth learning how to use it properly (with iterators, and things like that). This means that you can choose to use a vector, for example, and later you find that you'd rather use a list instead. No problem, just change vector to list and it all still works, just differently under the bonnet.

[prog_tom]

Well, my habbits are really ****. While I'm programming. Well when I get a bit bored and tired. I goto some PORNO PAge and... Mast******.
then get back to Programming.

[abdul]

If you go there then you will probably spend more time on those PORNO sites rather than programming!!