C++ Programming Tips

I am looking for tips for programming. I am in the second course for C++ and am wondering if there are any tips or any good habits you guys have, especially for those that have coded for a job.

Right now, when I start a project, I just sit down and code. This is ok for now, I think, but that's because the project is relatively small and simple. How does it work in the real world? I've heard that when one writes a function, they should test it immediately, so that if there are any bugs, you know from what function they are coming from instead of looking at the entire project. Does this sound right?

Any suggestions, tips, whatever will be very helpful. I don't mind links either. Thanks in advance.

It is good to test small chunks of code. Sometimes it is impractical to truly test a single function. To whatever extent you can, though, test each class. Also, as a minimum, you should have a good idea of what classes you will have an what they will be responsible for doing (how they interact, deal with resources, etc) before you start coding. Granted, designs sometimes change (even drastically) as unforseen events occur (which happen less frequently as you gain experience, and can make better predictions), but you really should have at minimum a rough sketch of what things will do. It is also handy to design the interfaces beforehand (very explicitly know what will be there) as part of the design as to how your class will interact with the outside world.

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.

Quote:

---

I am looking for tips for programming. I am in the second course for C++ and am wondering if there are any tips or any good habits you guys have, especially for those that have coded for a job.

---

Most jobs I have been on have been broken down like:
20% planning
30% coding
50% testing (this includes code revisions)

I have been on some projects that are small enough where we began coding the first day, but that is pretty rare :) Be prepared to do a lot planning when you work on larger projects. Most project managers hate it when plans have to be revised during the coding stage, so that's why they put so much emphasis on getting it right (as right as possible anyways) the first time.

A book you might want to check out is one called Rapid Development (sorry, I forgot the author name). The book is terribly boring to read, but it teaches you a lot about how to plan out software projects, and work on them as a team. That's another thing... when you code for a living, you will usually do it as part of a team, so teamwork is a necessity.

These are just my experiences though, I'm sure other people here have had completely different experiences in their jobs.

>>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 :D).

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

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.

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 :)

Quote:

---

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 :D

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)

---

Code:

---

float cX = (float)rPointX, cY = (float)(bounds.bottom - rPointY); //Typecast & convert from normal coords
float tempX, tempY; //Offset on source to centre the image

tempX = (cX*(cosine-1) - cY*sine);
tempY = (cY*(cosine-1) + cX*sine);

...

origX = (int)(((float)x + tempX)*cosine + ((float)y + tempY)*sine);
origY = (int)(((float)y + tempY)*cosine - ((float)x + tempX)*sine);

---

Perhaps the comment was not so informative as I had originally thought :rolleyes:

Quote:

---

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.

Pick up a good programming style and stick to it. (Choose how you indent. Choose how you lign up your braces, etc.)

printf, or I suppose in your case, cout is a great debugger. Sprinkle them all over when trying to track down a crash or incorrect values, and you'll speed up your hunt greatly.

If you get stuck, step away from what you're doing for a while. Take a walk. Take a nap. Do something else for a while. It gives your mind a while to chew on it while you're doing something else, it can also give you a fresh prespective when you come back to it.

Quzah.

Quote:

---

Originally Posted by Hunter2

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

---

You can post bad habits too, so that I know not to do them. ;)

Do you guys write like pseudocode or do UML designs (I hate them)? We started doing them and they are just very annoying. I guess I just haven't been able to use them effectively. Maybe for the next assignment.

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?

Quote:

---

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

---

I don't see debugging in there. Is that under testing? Is there much time spent debugging? Seems like it (ex. Firefox :)) Speaking of which, is there a large scale debugger that you guys use or just whatever is included with the IDE?

>>if (size = 3) instead of if (size == 3)
Not anymore. I did though.

>>Is there much time spent debugging?
Hopefully not, but often so. Especially when you're not familiar with some of the concepts you're using.

>>is there a large scale debugger that you guys use or just whatever is included with the IDE?
I just use the debugger included in MSVC 6.0 pro.

Quote:

---

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:D 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.

Quote:

---

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

---

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

Quote:

---

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. :mad:

>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 :)

And ask a many questions as you need on this board. The people are really helpful and will not quit helping you until you get it. (You will most likely quit before them, if it takes weeks).

my own personal method for debugging, which you may want to try ,is to not ever make mistakes. :D

Quote:

---

Originally Posted by The Brain

my own personal method for debugging, which you may want to try ,is to not ever make mistakes. :D

---

:p

I really never debugged anything until I started making an emulator. Then you really learn how a debugger works, and in some cases make your own little GUI debugger for your program.