Thread: C++ Programming Tips

1.plan
2.code
3.test
4.repeat steps 2 and 3 ad nauseam.

The point is get into good coding practices from the get go.

>I am looking for tips for programming.
Lurk here for a while and you'll find enough tips to make you sick. Some of them are even contradictory, so be on the lookout for opinions and stylistic issues. Other than that, if someone gives a bad tip they'll be called on it in a heartbeat.

>>I've heard that when one writes a function, they should test it immediately
That isn't always possible or practical, but generally that's a good idea. I've gotten into the bad habit of writing 80%+ of my program before compiling it for the first time, but with enough luck (and with enough practice) I don't run into any major bugs anymore even when I do so (minor things like forgetting a ++, quickly found and resolved). I'm trying to break the habit, but I'm often too impatient to stop - and I find that when I do stop, I tend to lose my train of thought and end up rewriting half of it poorly where normally it would have turned out OK. I suppose that has to do with my nature (sight reading was always my strength in piano ).

**EDIT**
>>wondering if there are any tips or any good habits you guys have
Ooops. Ignore my post, that's a BAD habit.

Do you experienced programmers tend to have a common syntax or logic errors? Like

Code:

if (size = 3)    instead of     if (size == 3)

Stuff like that?

I think everyone falls into that trap now and then when their brain is farting like coding late at night a simple trick to avoid this problem is this

Code:

size = 3 /* size gets 3 */
size == 3 /*size equals three or size is three */

I came across this a while ago and it seems to help me out.

I don't see debugging in there. Is that under testing?

That would be assumed under testing. Yes. perhaps I should have added.

1.plan
2.code
3.test
4.pull hair!! beat head against wall repeatedly
4.repeat steps 2 - 4 ad nauseam.

>Do you guys write like pseudocode or do UML designs
I use whatever design medium the project requires. For personal projects I'm not nearly as organized.

>Do you experienced programmers tend to have a common syntax or logic errors?
I have a nasty tendency to forget to dereference a pointer at the worst possible place. For example:

Code:

struct node *insert_node_r ( struct node *tree, int data, int *deeper )
{
  ...
  if ( deeper ) {
    /* Rebalance */
  ...
}

deeper is never a null pointer, so the tree is always rebalanced even when it isn't needed (or wanted). I wrestled with this particular bug for too long this morning.

>Is there much time spent debugging?
It really depends on the programmer.

>>I have a nasty tendency to forget to dereference a pointer at the worst possible place.
At least you won't run into type punning problems

>>It really depends on the programmer.
And to a certain extent, I believe, the budget

Originally Posted by Rune Hunter

Try not to abandon all of your projects...like me. I start something that sounds fun then I get into and I find out I can't do it or it takes to long so I quit, hoping I will come back to it someday.


projects I have abandoned so far:

texted based rpg Reason: got boring and confusing

project Chi Chi Reason: I found out I can't do what I wanted (I learned dlls tho )

(some people might remember this) A program to disply my 3d models when I was into making 3d models Reason: I can't do that



So please don't be like me.

Welcome to being a programmer without a job. This is so normal as to not be surprising so get used to it. If you go on
sourceforge you'll find tons of projects that have been abandoned or not even started as a result of lost of interest. The point is when coding, if you learn something from it, that is really what counts. Just don't have that attitude when on the job.
One key to programming if you don't want to lose it, is to find something that is interesting to you and explore it, otherwise you get bored ...quick.

Sometimes on larger projects, if I am using a piece of code that I just thought up or if I am not sure how it will work with what i'm using it for, I will make a simple console program and test the function.

Habit wise, spacing and neatness. I know its programmers preference but if you keep you code neat it will be much easier for you to debug. Also comment, even if noone else will ever see the code... comment.

You dont need to comment everything, somethings are self explanitory. But be sure to somment things that ( if someone looked at your code ) they wouldn't be able to figure out unless they went through your whole program.

Also avoid making long posts with run-on sentences and confusing wording because your grammar stinks, kinda like this post right here

But be sure to somment things that ( if someone looked at your code ) they wouldn't be able to figure out unless they went through your whole program.

I commented my image rotation code, because I knew I (and anybody else) would have no idea how it worked next time it was viewed. It didn't help, even though I spent half an hour writing a comprehensible comment for just one line

Everytime I try to make large comments, I feel like im making a tutorial, so I dont.

I always just right short little one liners.

Code:

// Save bit 7
result = ((number >> 7) & 1)