Need insight to C++

[Boltftw]

I am currently a college student struggling to get my program written for assignments. I want to get better and have a better understanding of C++. It is hard for me because I get easily confused, mix my variables up and I can not put in words what I want to write in code.

How do you fellow programmers handle assignments or problems? I just want some helpful insight so I can become a better programmer.

[Browni3141]

For the easy ones, I just open up a new file in my IDE and start coding. For the harder problems, I do something more like this:

1. Attempt to code the problem without really thinking about it.
2. Finish with code that fails miserably at doing what it's supposed to.
3. Scrap the project and start over.
4. Think through the problem working it out by hand if necessary.
5. Write the program in pseudocode.
6. Patiently write some quality code. Don't be lazy and just throw up a bunch of garbage like in step 1.

Feel free to skip steps 1-3. If your mixing up your variables, make sure you are giving them good names that are selfexplanatory. You shouldn't need comments to know what a variable is for.

[ultifinitus]

Well I don't ever have assignments (never taken a class) However when I'm working on a new problem I'll generally follow this formula>>

#if my project == small project && needed knowledge <= my knowledge

#Open up a new main file, and code away, if I get overrun with functions or need a class, separate the project into #multiple source files and headers files (but then it's not really a small project, is it?)

~else

~Get out my trusty whiteboard, write a nice little overview of what I want.

~-if it's a graphical program

~-get out my trusty pen and pencil and ream of paper. Draw every scene as I desire it.

~Next I start with all of the necessary files already separated (with dynamic growth as needed) and encapsulate ~everything to the best of my abilities. Now is the hard coding process, type type type, debug debug, break. repeat.


I generally try to set a day's goals, For instance I'm still working on my stinking app, which has been releasable for over a month. But I still want it to look better, so every day I set a goal of improvement. Today I wanted to encapsulate my pairing functionality in my server into a managerial class, which I did =)



Now I always run into road blocks. There will be something new I have to learn, something that I have to relearn, and things that just don't work as expected. Google is your best friend. Documentation is your second best. And forums like this and stackoverflow are generally the third. If you can't find more you can always ask specific people for help. Sometimes they just don't see the need, or have the desire to post publicly...

[rapidcoder]

I usually think about the problem far away from the computer until I know which algorithm to use and how to structure the code. For harder problems, sometimes I consult books or the Internet, to get inspiration. Then I just sit down and write the code, in small steps, checking each step if it works correctly, and writing appropriate unit tests. Writing the code usually takes me less than 1/5 of the whole time I was thinking of the solution, for the current project I work on (which I must admit, is pretty hard - see QUCS[1] source code to get the idea)

Another thing is, when I write enough code, I refactor it, because after writing the code I usually understand the problem better than before. It is just for improving performance, readability, and maintainability because at this time the code usually works.

Of course, for larger projects, the whole process is more incremental; nevertheless I usually don't start writing code if I haven't thought enough well what I want to accomplish, what I'm going to change and what it is going to break.

Trying to write the code without thinking first, in belief that "I'll change it until it works", is a bad idea. Even if it finally happen to work by accident, it probably has some serious flaws in it, and you also didn't learn too much.

I get easily confused, mix my variables up and I can not put in words what I want to write in code.

Maybe try to switch paradigms? Sometimes imperative programming is not a natural way of programming for some kinds of brains. Many people don't have problems learning to use spreadsheets (which is kind of data-oriented functional programming), but have terrible problems understanding imperative programming. E.g. try to learn Python. Really, really, great language to grasp the basics. When you know the basics, move back to C++.

[1] No, I'm not a devleoper of QUCS, we just work on a similar closed-source product. BTW, we have about 15x less code then they have, yet it offers similar functionality and orders of magnitude better performance, although it is run on JVM, not native compiled C++.

[simeonz]

I very much agree with what rapidcoder said. Work the problem from the inside out, don't peel the cabbage. Start simple. This is easier said than done though. Nothing can substitute some practice, because in reality the problems are not indefinite amount. After a while some stuff repeats itself. That's what I think makes the difference between good and bad grades. Some people have more practice behind them and are generally better acquainted with the subject. There's nothing you can do about it, except to hang on and improve yourself.

Regards

[Boltftw]

This is all very helpful information.

I believe my problem is over thinking the functions to much and this causes me to stress out a lot more then I should. I have tried the code method without thinking about the problem and I have just have issues debugging the darn thing. Perhaps, I will try and sit down and think about it more and eliminate words and phrases that would make the task simpler.

How would I keep my interest in coding? As of right now I get so stressed out that I am starting to lose interest. I am trying to have something spark my interest in C++ again and thus far nothing has. Perhaps, it is because it is a school assignment and I feel so much pressure to complete it.

[rapidcoder]

How would I keep my interest in coding? As of right now I get so stressed out that I am starting to lose interest.

I think everyone of us had some kind of "programming crisis". IMHO the best way to avoid this is to try to work on your own, personal programs, not just these required at school. The students who get the best grades are usually the ones that spent much time doing coding in their spare time. The best motivation comes, when your code works and solves YOUR problem (not the problem given at the assignment). This can get you in. I remember I've got extremely motivated after I realized I cannot win with the program I made for playing some logic game (actually this was at high school - reversi/othello). Or when I created a program that solved the resistor-bridge we spent 1,5 hour manually solving at physics class, in less than a millisecond. :D

[jsmith]

@Boltftw:

Many new programmers / students have trouble breaking problems down into smaller, more manageable, easier problems. For example, they get the homework assignment: "Write a program that reads student names and grades from a file, computes each student's average and letter grade, and outputs the results in order, sorted by average, to another file ...". They see it as one big problem. I see it as four small problems. Problem 1: read the data in from the file into an array or some data structure. Problem 2. compute each student's average and store it in the same data structure. Problem 3. Sort the data structure. Problem 4. Write the results to a file.

Automatically this suggests (at least) four functions to me, one for each problem. The input to problem 2 is the data read from problem 1. This suggests that problem 1's function returns the data, and problem 2's function accepts the data as a parameter. And so forth.

Now solve each problem independently. Write the code for problem 1, then write a few lines of code in main() that calls function 1 and outputs the data it read. Get it to work. Then work on problem 2. And so forth. The key is small, easy steps.

Many new programmers also get frustrated / stressed when the program doesn't work. In college, you aren't really taught how to debug programs when they don't work. Look at it this way: You wrote the code. If you understand the code, you know exactly what each line of code is supposed to do for any given input. So if a function doesn't work, try printing out information after each line of code and verify that the output of that line of code is what you expect. That will narrow down where the problem is in your code. For example: here's a buggy bubble sort:

void bubble_sort( int a[], int num_elems )
{
    for( int i = 0; i < num_elems; ++i )
        for( int j = i; j < num_elems; ++j )
            if( a[ j ] > a[ j + 1 ] )
            {
                 a[ j ] = a[ j + 1 ];
                 a[ j + 1 ] = a[ j ];
            }
}

Can you find the bug(s)?

HINTS: the above code actually is sort of an anchor sort in that instead of bubbling the lightest elements to the top, this one sinks the heaviest to the bottom. So after each iteration of the outer for loop, you know that the heaviest element should be on the bottom. The first step to debugging the above code then would be to print out the contents of the array after each iteration of the outer loop. Look at the output from the first iteration and see if it is right. (To do this, you'll need to write a simple main() that passes an unsorted small array to the function. At that point, you know _exactly_ what the array should look like after the first iteration.)

[ultifinitus]

Boltftw wrote:

How would I keep my interest in coding? As of right now I get so stressed out that I am starting to lose interest.

Well, find some cool projects to work on =)

If you want some ideas, just ask and I'll post some fun ones.

[bboy212]

for variables I use descriptive names and make my variable names as long as I need them using _ for spaces.

As for getting into programming I open up word and just sit there playing games or listening to music and type EVERYTHING t.hat gets into my head. Next I go through and cut out all the bad ideas then I organize the list. Then I get coding and just keep going till I have done something significant.

I also like to put all my functions in a .h file and keep my main as small as possible (under 50 lines of code). I also just design all my code to be reusable. That way next time you need a function that does X you can say oh yeah I did something like that back here
#include <back there> there now i just call this function and pass it a couple of values print its output to the screen and BAM! I'm done.

[Boltftw]

Thanks for all the wonderful information. I have used a lot of it over this weekend and I am not just on the debugging state of my program.

[ultifinitus]

Glad we could help!

Thanks for the follow up.

[dutChBZ]

A very interesting and inspiring thread!

I have this handy rule:

Analyse - Design - Implementation

analyse the problem;
design the interface;
code and test;
iterate this