MS PowerPoint and the OpenOffice equivalent (free) will also work. It all depends on what you are used to, how much money you want to spend, and how often you will use it. John
FWIW, when I took Comp Sci courses I learned, among other things, that you're supposed to avoid flowcharts by using extremely well-commented code, written so that six months from now you'll completely understand those comments.
FWIW, when I took Comp Sci courses I learned, among other things, that you're supposed to avoid flowcharts by using extremely well-commented code, written so that six months from now you'll completely understand those comments.
Flowcharts drive me crazy--for code maintenance, I wouldn't really use them--commented code, and even better, *clear* code is more readable to me.
But when I need to explain something to my boss, code is not gonna cut it, no matter how well-commented. That's just not what he does. Flowcharts, he understands.
Flowcharts drive me crazy--for code maintenance, I wouldn't really use them--commented code, and even better, *clear* code is more readable to me.
But when I need to explain something to my boss, code is not gonna cut it, no matter how well-commented. That's just not what he does. Flowcharts, he understands.
Absolutely--I feel that flowcharts tend to be more of a beginning-of-the-project thing, mostly so everybody can get on the same page with regard to what actions/decisions need to be taken in response to certain inputs or states. Once the spec' is hammered out and nailed down then other tools come to the forefront.
notwithstanding the need for charts and pretties for bosses and clients, flow charts can be amazingly helpful between the brainstorming phase and the code writing phase. they help to simplify logic and it's easy to identify early on where code repetition can be combined and decision paths can be streamlined.
notwithstanding the need for charts and pretties for bosses and clients, flow charts can be amazingly helpful between the brainstorming phase and the code writing phase. they help to simplify logic and it's easy to identify early on where code repetition can be combined and decision paths can be streamlined.
Absolutely. Still more of a pre-code rather than post-code tool though. I know that some code houses like to go to the extreme of having a full UML spec drawn out and verified before moving to code. Not all environments offer that kind of time frame, though.
That said, once you're done the code, better make sure that the flowcharts and other docs match what the code is actually doing.
Oh yeah, that does happen, and not only in Dilbert.
"Um. . .hi guys. I met with the clients yesterday and I might have told them that the product can also do your tax return, launch the Space Shuttle, and core apples. Can that be in the demo by tomorrow?"
Good point. I never did programming for pay so I never got to the point of having to explain it to others.
The CS courses did probably help get me a job in the USPTO (a mixed blessing).
When I was learning to program in the mid- to late-1960s, I was taught to flowchart first as a way to define the specific approach I was going to use.
I still do this, with pencil and clear plastic template. (I have several; two of them are so old they say "UNIVAC" on them.)
I can recall many instances where my flowchart effort made it obvious that something I thought would work would in fact not work, and other instances where the exercise of flowcharting made obvious a simpler, more elegant piece of coding.
Still, it isn't everyone's cup of chai. As a wise man once said, "There are more ways to roast a pig than by burning the house down."
When I was learning to program in the mid- to late-1960s, I was taught to flowchart first as a way to define the specific approach I was going to use.
I still do this, with pencil and clear plastic template. (I have several; two of them are so old they say "UNIVAC" on them.)
I can recall many instances where my flowchart effort made it obvious that something I thought would work would in fact not work, and other instances where the exercise of flowcharting made obvious a simpler, more elegant piece of coding.
I think it's still excellent advice and I wouldn't advise anybody *not* to learn it and do it. It's just one of those chores I don't care so much for. I think it has to do with the fact that in university in the early '90s I was chomping at the bit to get to the code; the classes in (what would later evolve into) UML were hard to sit through. I guess I hadn't yet figured out that the coding is a lot more fun when it has a reasonable chance of actually working.
As you say, flowcharting can wring things out that would be hard to spot just staring at page after page of code.
Still, it isn't everyone's cup of chai. As a wise man once said, "There are more ways to roast a pig than by burning the house down."
Let me see, when was the last time I used a flowchart. Believe it or not it was about 2 months ago when using multiple DS1820s and so I needed to implement the search rom algorithm. This algorithm is rather complex but Maxim provide a flowchart (See page 5 of AN162) and this enabled me to implement the algorithm in assembler without too many headaches. I think what I am saying is I find it much easier to write code when I have a correct flowchart.