brain itch

As many of you will know, for those that are in college finals are coming soon.I already have mine, and well, i did crappy on it. I want to do the asignment right, just for pride reasons, and if this thread is deleted and or not answered, well i understand. but i have come to the conclusion my codeing is , well, in a word worse than the sound of nails on a chalkboard. so , i come to experts in giving me aid.

the program details are thus:

its a bank account program that allows the user to keep track of his checking account. the user can

make deposits
write checks
do witdthdrawls
search for check by payee
search for check by date
show listing of all deposits/checks made
display current balance

and saves and loads the information with the filenames of both input file and outputfile be chosen by the user.


i have enclosed what i have sent in as my final, i appoligse for its patheticness

As it is, it is very rudimentary. The assignment is large and this has at best some 1% of it (wouldn't count as a fair effort to solve the problem oneself, IMO).

Code:

---

        case 2:
        //inputting of checks
       
        cout<<"please enter the name of payee"<<endl;
        cin>>payee;
        cout<<"please enter the date the check was written."<<endl;
        cin>>date;

                break;

---

Those variables are undeclared.

The rest is more or less completely unimplemented. I suppose you need an array (container) of accounts and another one of checks. Then you go from there.

Quote:

---

just for pride reasons

---

>_<

If that is what you sent for a final, you deserve to fail. You didn't even attempt to implement %80 of it. What did you expect? What do you want from this forum? The other %80 of the implementation?

Pride? You have none.

Soma

http://cboard.cprogramming.com/c-pro...t-process.html
Posting something which compiles would be good.
It's just a lot of small steps, don't try to write the whole thing at once.

Implementing each function, even if it's only

Code:

---

void balance ( void ) {
  cout << "This is balance" << endl;
}

---

With that, you can check all your menu code, user selection etc.

Having done that, maybe have a think about what next...

Quote:

---

Originally Posted by Salem

http://cboard.cprogramming.com/c-pro...t-process.html

---

Writing the comments is the last step? Ugh.

Quote:

---

Writing the comments is the last step? Ugh.

---

I only write comments when I come back to my code later, can't understand some part of it, take an hour to figure it. Then I comment the thing that I couldn't understand at first for the future :)

But even those comments have so far been useless, because when I come back again, I'd have problems with yet other parts of the program.

Quote:

---

Originally Posted by brewbuck

Writing the comments is the last step? Ugh.

---

Sometimes it's useful to write the comments only after you've written each function. But, usually, I agree, it's way better to write the comments as you go.

Quote:

---

Originally Posted by EVOEx

Sometimes it's useful to write the comments only after you've written each function. But, usually, I agree, it's way better to write the comments as you go.

---

I try to avoid commenting if possible, because it indicates the code isn't clear enough. But when a comment is truly necessary, I usually write it before writing the code itself.

But back on topic, the best approach to a reasonably realistic problem such as this one, is to design and understand the necessary data structures before writing any code. Once the data structures are defined, the code will naturally fall out from that.

Quote:

---

Originally Posted by brewbuck

I try to avoid commenting if possible, because it indicates the code isn't clear enough. But when a comment is truly necessary, I usually write it before writing the code itself.

---

I agree here, too. Most (95%) of my functions are less than 5 lines, in which case I generally don't write any comments, except for the per-function comment I always add. Usually, whenever a function needs a blank line, I also think it needs a comment - that's my rule of thumb, even though I don't always follow it myself.

I use fewer comments than I see in most source and I feel guilty about it, which probably means I should add more at the end.

Quote:

---

Originally Posted by brewbuck

I try to avoid commenting if possible, because it indicates the code isn't clear enough.

---

Begs a lot of questions about how clear, etc. I'm usually conservative this way; I tend to think: this is clear enough. Then later I come back and think hey, you know a couple of words here will save you a couple of minutes later on, every time you come back. So the first time I come back and recognize that, I add the comment.

I guess if we were all omniscient this would not be a problem, but IMO current standard practices wrt documenting code are way, way, way behind current standards wrt coding itself. So I don't feel too guilty.

Feel free to post an updated guide...

^_^v

Code:

---

while(problem_not_solved)
{
  think();
}
code();

---

Quote:

---

Originally Posted by Salem

Feel free to post an updated guide...

---

I keep meaning to do something on a couple of related issues:

1) How to premise test syntax usage.
2) How/why to write "as short an example as possible which demonstrates a specific problem".