The following instructions assume that you have already picked a program to write.
First of all, I'm sure you recall that you should not begin writing code before you've thoroughly read the problem assignment -- including the thought-provoking questions. The assignment itself describes the 'problem' you are trying to solve. The sample run (if present) gives clues to details that might not have been obvious from the description (often including notes to point these issues out). But the thought-provoking questions bring all of these details into perspective and try to make sure you are clear on all aspects of the program you are about to (or, at worst, are) writing. So at least read them first!
Also take note (the TPQs will help here, too) of the topics/techniques you are supposed to be demonstrating with your program. These are listed at the very top of the assignment under 'Topical Information'. It is often possible to solve a programming assignment with many different approaches, but I've created these assignments with the goal of helping you understand certain ideas. If you solve a problem with approach B and I was trying to get you to see technique A more clearly, I can't give you full credit. Certainly you may have learned something, but it wasn't the point of the exercise. *shrug* Sorry...
Now you need to decide about the layout your program is going to have: its User Interface (UI). How will you ask the user for information? Are your prompts on the same line as their typing or the line above? Are you mundane, acerbic, witty, or something else entirely? Are your results simply labeled or layed out in fancy columns? Are your results simply stated in a set of English sentences? What is the title of your program?
Once you've decided these things, actually writing the program will be easier because the 'cout' parts will flow from this guiding design decision.
Your job in writing a program to solve an assignment is NOT to mimic the sample run exactly. Your program must accomplish the same aims (have the same results), but can do it in a different 'way'. You can design the look-and-feel of your program. The only thing that must remain the same is the overall structure (opening, input, results, closing) and the results that are printed (but not how they are printed).
That said, I know that not everyone feels creative all the time, so if you want to mimic the sample run, go ahead. *shrug* Who am I to stifle your boredom?
If your UI choice above wasn't 'mundane', perhaps you'd like a theme? There's the usual science fiction, fantasy, country & western, horror, mystery, romance, etc. But there are cross-genres, too: anime, puppets, live-action, etc. (*grin* Just kidding, kinda hard to do those in a text interface. *chuckle*) The text in your program shouldn't be an eclectic mish-mash of styles but rather should have a flow to it. A theme isn't necessary, of course, but can help to accomplish that flow.
Looking through the problem description, sample run, and TPQs, you should get an idea of what results your program should produce. Note those as 'output variables'. These will be our entire reason for existence during this programming process. We may eventually decide that they can be simply printed from their calculation instead of stored as variables, but for now it is fine to just say 'variables' for all of them.
You should also be able to decipher what information the program is supposed to read in from the user. Note those as 'input variables'. Everything must have a beginning and an ending: these will be our beginning. Also, these must be variables because cin can't store values directly into a calculation -- it needs a [writable] memory location to put the values into.
Look through the description for any formulas you might need to transform the input into the output. If none are given and yet are clearly needed, they are probably standard math or science formulas that are considered 'common knowledge'. A quick Google search or look through an old textbook should bring them to light.
Also, while looking for/through your formulas, take note of any likely candidates for constants. (Remember, if it is a literal value with a name-able meaning, we'd prefer it to be a constant. When you can't come up with a name for it, just place the original formula in a comment to show that it is a standard value.)
Our general setup is to:
All of this will be placed inside the main function/program between the
open curly brace ({) and the return statement (return
0;). And, of course, we can't use all those variables/constants
we just noted without first declaring them. These declarations go
immediately after the open curly brace of main. (Constants can also go
between the 'using namespace std;' line and the 'int
main(void)' line.)
Refer to your notes to see the proper syntax of declaration statements for variables and constants; of cout statements for prompts, labels, and messages; of cin statements for reading; and of assignment statements for calculations.
Remember that you must declare variables/constants before you can use them. You must prompt before you read. You must read before you calculate. And you must calculate before you print results.
As the semester progresses and you are using more functions from standard
libraries, don't forget to #include them at the top of the
program (above the 'using namespace std;' line). Also, once
you learn to write your own functions (and forever after!), try to break
longer processes down into more manageable steps and try to make 'repeated'
code into parameterized functions that you can re-use (within a single
program and/or across multiple programs).
Don't forget to consider style at every turn. Make sure you are using
blank space effectively both within your code and in your UI. Make sure
your code is indented a [consistently-sized] level within each pair of
curly braces ({}). Make sure you've named your variables,
constants, etc. with clear, understandable names. If any calculations are
at all tricky, make sure you've commented before (or to the right) of them.
(Also comment any functions, branches, or loops you may have written...see
your notes about these.) And, make sure your lines are no longer than
72-78 characters so that the 'printer' doesn't chop them off. (See also the
'printing' notes for more on detecting and
avoiding this problem...as well as saving a small forest by the end of the
course.)
When in doubt about a style issue, always look it up on the master style list. In fact, why don't you just go ahead and add that page to your 'Top 10 Things to Read before Bed' list. *smile* *grin*
In the 121 examples directory under 'basics', you'll notice one called 'math'. In this example are an actual assignment, the info file for the solution, the answers to the thought-provoking questions, the actual program to solve the problem, and even a completed script for handing in.