|
void has asked for the wisdom of the Perl Monks concerning the following question:
Many, many moons ago (in college). I took some BASIC classes and the instructors always stressed the importance of planning our programs. The instructors really, really pushed flowcharting a program before a single line of code was written. Having taken up the Perl torch about 6 months ago I was wondering if this is still the case today? Are classes the same today and more importantly do programmers continue this process after they reach the real world (work) or do most just sit down and start hacking on the keyboard?
"The Universe is not only more complex than we imagine, it is more complex than we can imagine." - Albert Einstein |
Re: Go with the flow?
by Abigail-II (Bishop) on Jul 31, 2002 at 15:06 UTC
|
When I started at university, the professor who was going to teach
us "Introduction to Programming" stated that people who had used
flow charts in the past started with a disadvantage. During my entire
CS masters, I never worked with flow charts.
I don't believe flow charts help you in creating structured programming.
On the contrary, I believe they help you create spagetti programs.
It's something from the fifties and sixties, when goto was a popular
statement.
Flowcharts don't help you design a datastructure. Flowcharts don't help
you with efficiency issues. Flowcharts don't help you in proving something
to be correct. Flowcharts don't help to uncover design flaws. At best,
flowcharts help you to determine the control flow of your program,
but it doesn't help you to determine whether the flow is correct or not.
Design is good. Design doesn't necessary have to be done on paper.
Just taking the time to think about the problem, and dividing it into
subproblems is design too. Obviously, the more experience you have, the
more you can avoid using paper to do design.
Most of the design I do on paper (or a whiteboard) consists of drawings.
But not of the control flow - I never design control flow. With a good
design, the control flow will be obvious anyway. But I do make drawings of
datastructures, relations of pieces of data, or state diagrams. Different
problems need different designs. Sometimes a datastructure is going to be
the core of the program, and given a good datastructure, the algorithm
is obvious (and then all you are left with is the implementation). But
sometimes the datastructure isn't important or it's obvious, but the
design needs a state diagram. Recently, I had to parse a logfile and
extract quite some information. The datastructure wasn't too hard,
a quadrupled nested hash/array, but because the logfile didn't have a
consequent format and had entries missing, a state diagram was needed
to make a good program.
Abigail | [reply] |
Re: Go with the flow?
by tjh (Curate) on Jul 31, 2002 at 14:45 UTC
|
| [reply] |
Re: Go with the flow?
by Basilides (Friar) on Jul 31, 2002 at 14:26 UTC
|
Design is a *major* part of programming, and at my college, a number of modules are given over to it exclusively.
Any program where you can't comfortably remember every aspect of it straight away, basically anything that isn't a short straight procedural routine, is a good candidate for some kind of design.
If it involves more than one programmer, one of the established methodologies is probably best--UML or even the dreaded SSADM for really big things--but if it's just you, you can pretty much make up your own system, as long as it makes sense to you.
Always best to have at least a basic design before you even start tho', especially if you're using OO.
As a programmer, this annoys me as I'm itching to code, but I can assure you from bitter experience, the amount of time you waste when you don't plan ahead (especially with a forgiving, easy-to-code language like perl, where you can code for miles without stopping to look back over things) is way more depressing than having to sit down with a pen & paper when you want to start typing. | [reply] |
Re: Go with the flow?
by redsquirrel (Hermit) on Jul 31, 2002 at 14:08 UTC
|
This is not specific to Perl, but you may find the literature on Extreme Programming relevant to your question.
I would suggest starting here or more specifically, here.
--Dave | [reply] |
Re: Go with the flow?
by TStanley (Canon) on Jul 31, 2002 at 14:07 UTC
|
IMHO, it depends on what you're doing. If it is going to be a short, simple script, I don't bother. But if I am going to be writing a large and involved program, I sit down with pencil and paper, and I start planning out the basic design of the program. I also check CPAN to see if there is something out there that would make the task infinitely simpler as well.
TStanley
--------
Never underestimate the power of very stupid people in large groups -- Anonymous | [reply] |
Re: Go with the flow?
by Tomte (Priest) on Jul 31, 2002 at 14:34 UTC
|
If 'flowcharting' means ' drawing very, very exact Nassi Shneyderman diagrams', my answer (and the answer of every coder I know) is: No Way!
But if it means to structure things before jumping head-first into the realization-phase I'd say definitly: yes
"Pen-And-Paper-Thinking" helps IMHO a lot, even for small but complex projects, and I start nearly everything with a pen and a scratchpad
regards,
tomte | [reply] |
Re: Go with the flow?
by mugwumpjism (Hermit) on Jul 31, 2002 at 14:47 UTC
|
Flowcharts are still of ultimate importance. Someone who does not rely on drawing them is trying to hold all that information in their head, which is a bad place for it.
However, since the days of BASIC, imperative or procedural programming has gone out of fashion. So, now the flowcharts denote the structure of the objects primarily, and the actual flow of the program is analysed in other ways.
The flowchart language is called UML - Unified Modelling Language.
| [reply] |
Re: Go with the flow?
by dragonchild (Archbishop) on Jul 31, 2002 at 15:38 UTC
|
Flowcharting a function or procedure is a good thing. For one, if your flowchart is too big, it's a candidate for refactoring, at the very least. (Too big means more than 7-10 box-thingies.)
The underlying question of "Should I design before I code?" should be answered as thus:
If you don't, you're dumb.
Unfortunately, if you get into the corporate world, you (more often than not) have managers who push deadlines over design, resulting in a cancerous blob of an application. *shrugs*
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |
Re: Go with the flow?
by Dog and Pony (Priest) on Jul 31, 2002 at 15:20 UTC
|
Really way back in high school(?), we were taught to program in something that resembled BASIC, I think it was called COMAL or something, and then those charts also were a biggie - it was called "Jackson Structured Programming" I think. A google search would probably turn up some examples, and scare you off. :)
It didn't help us create programs then, and I seriously doubt it would now either. Rather the opposite, as it was then too, I'd say.
On the other hand, I do think that all computer graphics should go back to "Turtle graphics", which was what we had back then. That'd be sweet. ;-)
You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue. | [reply] |
|
|
