how to make a plan of how you implement a program?

T

takashi

Hi, I have a question. I am learning about how to use c++ language. I
have attempted to make my own programs, using the knowledge that I have,
but sometimes when I get stuck on writing a code, it took me a long time
to figure out what I should do. For instance, I was writing a program
which tells you all the prime numbers that are less than the number you
input on the console. It was a very short program, but it took me a
while to write the code successfully. Then I thought that the reason why
I got stuck was that I started writing the code without having any plan.
I just sat down in front of the computer, and started writing the code.
I heard that some people knows how to make a over-all plan of how he
wants to implement his code before he actually starts writing. I heard
about drawing a flowchart, then somebody said that a flowchart is not an
effective way for a large program.
Could anybody tell me how more experienced programer makes his plan
for writing his code, so that there is less chance that he gets stuck
while he's writing his code?
Thank you very much, and have a good day.
 
A

Alf P. Steinbach

Hi, I have a question. I am learning about how to use c++ language. I
have attempted to make my own programs, using the knowledge that I have,
but sometimes when I get stuck on writing a code, it took me a long time
to figure out what I should do. For instance, I was writing a program
which tells you all the prime numbers that are less than the number you
input on the console. It was a very short program, but it took me a
while to write the code successfully. Then I thought that the reason why
I got stuck was that I started writing the code without having any plan.

Always a good idea to have a plan.

I just sat down in front of the computer, and started writing the code.
I heard that some people knows how to make a over-all plan of how he
wants to implement his code before he actually starts writing. I heard
about drawing a flowchart, then somebody said that a flowchart is not an
effective way for a large program.

That's right, assuming that by "flowchart" you mean the usual "execution
path flowchart".

A flowchart is good for deducing what spaghetti code does, and that's
just about it. It's good for that purpose because it makes the relationships
visible to the eye, and it _can_ be used for that because it doesn't impose
any constraints, and so can represent any and all features of spaghetti
code.

But for the very same reason it's not a good representation to start
with: to obtain something that is easy to understand as code you need to
constrain yourself much more than is natural with a flowchart; one way is to
limit yourself to the "structured programming" constructs of C++, such as
while, do, for, if-else.

Try to master the level of algorithms and such first, corresponding to
individual member functions in OO programming.

But do keep in mind that as you progress to larger systems / higher levels,
focusing on execution flow will generally be The Wrong Thing To Do.


Could anybody tell me how more experienced programer makes his plan
for writing his code, so that there is less chance that he gets stuck
while he's writing his code?

It is a matter of being lazy in an intelligent way... ;-)

Don't decide things that don't need to be decided yet, because that may
lock you into a very suboptimal path at a point where you don't have enough
information and understanding to make an informed decision.

Do focus on possible showstoppers, however.

Other than that plans depend very much on the concrete system and on the
level of coding -- function, module, class, package, system...

Plans also depend very much on who makes them and who's intended to
execute them, and do not have very much to do with C++ as a language.

Thank you very much, and have a good day.

Hth. anyway
 
J

John Harrison

takashi said:
Hi, I have a question. I am learning about how to use c++ language. I
have attempted to make my own programs, using the knowledge that I have,
but sometimes when I get stuck on writing a code, it took me a long time
to figure out what I should do. For instance, I was writing a program
which tells you all the prime numbers that are less than the number you
input on the console. It was a very short program, but it took me a
while to write the code successfully. Then I thought that the reason why
I got stuck was that I started writing the code without having any plan.
I just sat down in front of the computer, and started writing the code.
I heard that some people knows how to make a over-all plan of how he
wants to implement his code before he actually starts writing. I heard
about drawing a flowchart, then somebody said that a flowchart is not an
effective way for a large program.

That's correct, a flow chart is far too primitive for large scale design.
Some people use something called UML (Universal Modelling Language). There
are lots and lots of books on this if you are interested.
Could anybody tell me how more experienced programer makes his plan
for writing his code, so that there is less chance that he gets stuck
while he's writing his code?
Thank you very much, and have a good day.

I very rarely plan. What I do is regularly review the code I've written. If
I feel that I'm getting bogged down I go back over what I have written and
if necessary rewrite part (or all) of the code I've written so far, learning
the lessons from what went wrong the first time. I read a quote once that
said every program could benefit from being rewritten from scratch at least
once, I agree with that.

But I'm not trying to knock planning ahead, its works for many people, its
just that I'm not very good at it. I value good design a great deal, its
just that I find the best way for me to achieve good design is to start
coding.

John
 
K

Karl Heinz Buchegger

takashi said:
Hi, I have a question. I am learning about how to use c++ language. I
have attempted to make my own programs, using the knowledge that I have,
but sometimes when I get stuck on writing a code, it took me a long time
to figure out what I should do. For instance, I was writing a program
which tells you all the prime numbers that are less than the number you
input on the console. It was a very short program, but it took me a
while to write the code successfully. Then I thought that the reason why
I got stuck was that I started writing the code without having any plan.
I just sat down in front of the computer, and started writing the code.
I heard that some people knows how to make a over-all plan of how he
wants to implement his code before he actually starts writing. I heard
about drawing a flowchart, then somebody said that a flowchart is not an
effective way for a large program.
Could anybody tell me how more experienced programer makes his plan
for writing his code,

The most important thing for a newbie to learn: paper and pencil are your friends.
Newbies often start coding without knowing how to actually solve the problem
in question without a computer, just by using paper and pencil.

And that is the thing you should focus first: Whenever you attempt to write
a program to solve a problem, you *must* be able to solve the very same
problem by hand. Without being able to do that, you can't write a program.

So do some experiments on paper and watch yourself.
Which steps did you take?
In what order?
Why exactly did you do this step right now?
What was the trigger for performing that step right now?
If you needed to repeat something, how often did you do that? Why that many times?
Are there relations between numbers on your paper? What are those relations?
....

If you watch yourself closely, you will end up with a cook book recipe.
Write it down in your own language (don't think about a programming language
right now). Test your recipe, by solving some more problems. Did your recipe
work in all cases or where there some subtle bugs? If possible try to give
your recipe to somebody else (the less he/she knows about your problem, the better).
Is that someone able to solve your problem by just using your recipe? If no,
where are the problem areas? Is it possible to refine them? Refine them!

Once you have that recipe, you are redy for the next step. Translate your
recipe into a programming language and test it on the computer.

You are done!


Of course the whole process shortens over time because you have gained
experience and have learned some algorithms and/or code patterns by heart,
but basically it still works the very same way for every program:

You can't write a program to solve a problem, if you don't know
how to solve the problem by hand with paper and pencil.
 
E

Elephant

Read the book "Modern Structured Analysis" by Edward Yourdon 1989, or
something similair.

System analysis ( what the heck are we making? - information ).
System design ( how is our system gonna do this? - abstracting ).
Make the system.

That is one lousy summary, but the idea works for anything you have to
program that is starting to get complicated.
For a small program, your done pretty quick. For a large project, analysis
and design can be more work then making the system.
 
J

jeffc

takashi said:
Hi, I have a question. I am learning about how to use c++ language. I
have attempted to make my own programs, using the knowledge that I have,
but sometimes when I get stuck on writing a code, it took me a long time
to figure out what I should do. For instance, I was writing a program
which tells you all the prime numbers that are less than the number you
input on the console. It was a very short program, but it took me a
while to write the code successfully. Then I thought that the reason why
I got stuck was that I started writing the code without having any plan.
I just sat down in front of the computer, and started writing the code.
I heard that some people knows how to make a over-all plan of how he
wants to implement his code before he actually starts writing. I heard
about drawing a flowchart, then somebody said that a flowchart is not an
effective way for a large program.

For small programs, think "algorithms". For larger programs, if you are
using OO, there are many books on OO design. Basically, it boils down to
simulating the real world problem with the classes/objects you think you'll
need, and how they are going to related to each other. If not OO, then you
have to think about what data (information) you want to keep track of, and
what you want to accomplish with that data. To understand the program, you
first have to understand the problem fully. I suspect you don't fully
understand the problem. Just talking it over with another programmer can
help.
 
C

Chris Newton

takashi wrote...
I am learning about how to use c++ language. I have attempted to make
my own programs, using the knowledge that I have, but sometimes when
I get stuck on writing a code, it took me a long time to figure out
what I should do. [...] Could anybody tell me how more experienced
programer makes his plan for writing his code, so that there is less
chance that he gets stuck while he's writing his code?

That's a very deep question, and there are whole books of advice on this
subject, with various different approaches. I would suggest that you
start by working on two skills that are generally useful in any
programming you do: using pseudocode and modular design.

If you're going to implement an algorithm in C++, then obviously you
must know what it needs to do before you start. If you can't describe
what it does in natural language (or mathematics, if you prefer) then
you can't possibly implement it in a programming language.

For example, suppose I've got a file of the form
Fred Smith, (e-mail address removed)
John Doe, (e-mail address removed)
and I want to write a function that reads in this file, extracts the
name and e-mail address from each line, and stores them somewhere for
future use.

I might represent this algorithm slightly more formally, in
"pseudocode", as follows:
Open file
For each line of text in the file
Parse the line, extracting name and e-mail address
Store name and e-mail address
Close file

It doesn't matter exactly what notation you choose to use, and with
experience you'll develop your own shorthands that you find useful. The
important thing is that this is a more structured representation of your
algorithm.

Some people prefer to use various diagrams for this step, or to start
with diagrams and then turn them into pseudocode. Personally, I've
always found flow charts and such cumbersome, but to others they're much
more natural. Use whatever works best for you.

Once you've got some pseudocode, however you choose to write it,
implementing the real thing is a piece of cake: you just substitute
formal C++ for each step in the pseudocode.

Personally, I find it useful to turn my pseudocode into comment lines,
and then replace them one at a time. For example, I can open a file in
C++ by creating an ofstream object, and that also takes care of the
closing at the end of the function, so my code becomes:
ifstream data_file("addresses.dat");
// While a line of text is available
// Parse the line, extracting name and e-mail address
// Store name and e-mail address

I continue to replace each line of pseudocode systematically with some
C++ that implements it:
ifstream data_file("addresses.dat");
string line;
while (getline(data_file, line)) {
// Parse the line, extracting name and e-mail address
// Store name and e-mail address
}
and so on.

In this case, the remaining steps might each be quite complicated, so
maybe it's best to put them in separate functions, which you can write
later:

ifstream data_file("addresses.dat");
string line;
while (getline(data_file, line)) {
string name;
string address;
Parse(line, name, address);
Store(name, address);
}

(Obviously there are more elegant ways of doing this in reality, but the
above is intended to illustrate my point about replacing pseudocode
iteratively.)

When you've finished replacing your pseudocode with C++, you wind up
with a completely implemented function. Essentially, this process breaks
a hard question ("How do I implement this algorithm?") down into lots of
simpler questions ("How do I represent this loop using tools in C++?").
It's much easier to answer simple questions. :)

The other skill -- how to design a larger program -- usually comes down
to one key skill: modular design. There are so many books and on-line
articles about this that there's little point in my saying much here. If
you're into OO, you might read a few of the articles over at ObjectMentor:
http://www.objectmentor.com/resources/articleIndex
They have a very heavy pro-OO bias, and there are certainly other useful
approaches you can take, but they do a good job of illustrating the
basic principles, and an inexperienced programmer could learn a lot of
useful techniques there.

Hope that helps,
Chris
 
E

E. Robert Tisdale

takashi said:
Could anybody tell me how more experienced programmer makes his plan for
writing his code, so that there is less chance that he gets stuck while
he's writing his code?

1. Identify all of data objects in your problem.
2. Group the data objects of the same type together.
3. Implement the Abstract Data Type (ADT) for each group as a class.
An ADT specifies
a. all of the values that an object of a particular type can have and
b. all of the methods which can be applied to an object of that type.
4. Solve the problem by instantiating the objects and applying
the appropriate methods for objects of each type.
 
T

Tom Mullan

takashi <[email protected]> said:
Hi, I have a question. I am learning about how to use c++ language. I
have attempted to make my own programs, using the knowledge that I
have, but sometimes when I get stuck on writing a code, it took me a
long time to figure out what I should do. For instance, I was writing a
program which tells you all the prime numbers that are less than the
number you input on the console. It was a very short program, but it
took me a while to write the code successfully. Then I thought that the
reason why I got stuck was that I started writing the code without
having any plan. I just sat down in front of the computer, and started
writing the code. I heard that some people knows how to make a over-all
plan of how he wants to implement his code before he actually starts
writing. I heard about drawing a flowchart, then somebody said that a
flowchart is not an effective way for a large program.
Could anybody tell me how more experienced programer makes his plan
for writing his code, so that there is less chance that he gets stuck
while he's writing his code?
Thank you very much, and have a good day.
You will need to learn UML which in turn will teach you object oriented
software development principles. There are loads of books on the subject
or you could take a course.

good luck
Tom
 
B

Bob R

[add to Chris' fine thoughts] [my 0.0002 pico-cents worth]

1 - write the DOCs first. What do you expect the user to input, what
can the user expect as output. What does the program do. This step
should parallel the psudocode Chris was showing.

2 - (this one is very important, and often overlooked by 'newbies' and
(some)'experienced')
Write the ERROR handling code. If an integer is expected, what do you
do when an float is typed, or 'three' is typed? Think of all the ways
a user might abuse your program, and handle it ("Hey ding-dong, I
asked for an integer, not what you typed!! Try again."). If you do
this step early, you can avoid some headaches. How many times have you
run a program, only to be dumped back to the system with no idea what
went wrong?


Now if I could only learn to follow my own (and Chris') advice! <G>
[ code first, look for SIGSEGV causes later!! ]
--
Bob R
POVrookie
--
MinGW (GNU compiler): http://www.mingw.com/
Dev-C++ IDE: http://www.bloodshed.net/
V IDE & V GUI: http://www.objectcentral.com/
POVray: http://www.povray.org/
Good C++ book: http://www.mindview.net/Books
alt.comp.lang.learn.c-c++: ftp://snurse-l.org/pub/acllc-c++/faq
 
M

mjm

I think at this level there is no need for planning.

This is not meant to belittle you in any way.
I started out in exactly the same way and it took me a very long time
to write small programs. This is simply inevitable.
You get faster as you program more and that is exactly what it takes.

Find a problem that interests you is reasonably complex so it will
take you a long time to work on (a year or so) and start working on
it. You make a small partial solution of a special case under
restrictive assumptions with limited functionality and then a little
bigger one under slightly less restrictive assumptions with a little
more functionality and so on.

I'd say finding the interesting project is what is most important.
Homework problems or book examples are very poor substitutes for that.
 
C

Chris Newton

Bob Jacobs wrote...
Gosh, how did we manage all these years, without UML? ;-)

We drew class diagrams, sequence diagrams et al. using other notation
instead, and got on with it without invoking the Elder God Hype.

:eek:)

Chris
 
G

Govindan

E. Robert Tisdale said:
1. Identify all of data objects in your problem.
2. Group the data objects of the same type together.
3. Implement the Abstract Data Type (ADT) for each group as a class.
An ADT specifies
a. all of the values that an object of a particular type can have and
b. all of the methods which can be applied to an object of that type.
4. Solve the problem by instantiating the objects and applying
the appropriate methods for objects of each type.

Some programmers start typing their code into the PC,
they first write some comments and then fill in the code thereafter.
They may refer to their previous working code or somebody's else's code
for useable design patterns or idioms to use in their solution.
They may even refer to some Algorithms text to get some helpful
datastructures and pseudocode
if the programming problem is a particularly hard one.

Using pencil and paper to draw some classes and attributes and jotting down
some tricky algorithms in short pseudocode
may help in school projects or assignments where the solutions may not be
readily available in any textbooks or journal articles
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top