Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Up until now I've been drawing out flow-charts for my software on paper before working.
Does anyone know of any software that is intended for engineering flowcharts?
Powerpoint/Word are both a pain and I haven't found anything I love online yet.
Up until now I've been drawing out flow-charts for my software on paper before working.
Does anyone know of any software that is intended for engineering flowcharts?
Powerpoint/Word are both a pain and I haven't found anything I love online yet.
Does anyone know of any software that is intended for engineering flowcharts?
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.
You also might want to look at
https://www.amazon.com/Strategies-R...=sr_1_1?ie=UTF8&s=books&qid=1220973677&sr=1-1
There is S/W that implements the ideas in this book.
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.
Different tools for different purposes.
Torben
Evening Torben,
I agree with the need for flow charts when you have a client/boss in the project.
Some clients insist on a flow chart to be included as part of project submission/proposal/quotation.
Dont you ever sleep.?![]()
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.
That said, once you're done the code, better make sure that the flowcharts and other docs match what the code is actually doing.![]()
that'd be additional "features" added after the flowchart was made![]()
But when I need to explain something to my boss, code is not gonna cut it, no matter how well-commented.
This probably dates me . . .
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."