+ 5
Is it really important for programmers to make a flowchart of their code before coding?
12 Answers
+ 20
I think of flowcharts being useful in the following scenarios:
1. Newer programmers who are still working on getting the abstractions, patterns, and logic straight in their heads.
2. Senior programmers who are mentoring newer programmers who need flowcharts to better understand the design.
For the most part, the flow is pretty clear in my head and I'm just cranking away at all the various pieces as quickly as my fingers can type.
It's like how I see an artist begin a sketch on a blank canvas where the various strokes and curves make no sense at first and then some amazing face or landscape or structure begins to take shape.
I can't imagine how that artist knows where each stroke goes in perfect placement, but they do.
You will too, with code. The more you practice and understand patterns (either well established design patterns or your own) the more you will be able to naturally see the flow in your mind and find yourself coding it without effort.
+ 10
In my case, I rarely use a flowchart. However, I do pseudocode instead. Both practices help map out your plan in implementing the final code.
+ 10
Flowcharts were more common in the days when everything was procedural. However, it is necessary to have an algorithm (a list of pseudo code steps) documented somewhere (even if that's just in your head). Whether you want to represent the algorithm in the form of a flowchart is up to you and/or your organisation if you work for one.
+ 9
In my case...I do have the pseudo code for what I want to code in my mind as I already know what I want my program to do in advance...the next part is simply dealing with the syntax and semantics of the language I am using. I believe the secret is breaking up your problem into mini problems simple enough for your brain to grasp.
+ 9
True David Carroll . As long as you know what you want the program to do the rest will be fine. The good thing with this approach to me is that I can code even with a new language as long as I know the basics...then after some time as I understand the deeper concepts about the language I review my code along way. This way I manage to kill two birds with a single stone i.e. my program working and learning new language.
+ 8
Brian I 100% agree that it is a common practice within organizations to create flow charts and diagrams post delivery of the code.
However, we've got several application diagrams that are already outdated with just a couple of sprints. 😉
+ 7
It is not necessary, but it helps, if the program's logic is complex, then writing a flowchart will help you see how the program is suppose to run and enable you write better code.
However, if the code is fairly basic, like a bubble sorting algorithm, then you don't need the flowchart.
+ 7
</Dan Rhamba> Your approach is good. You're thinking of your implementation in pseudo code, rather than some specific language.
This works well for polyglots, like me, where we tend to work in multiple languages and platforms almost seamlessly.
While I may sometimes get tripped up with some syntactic nuance of how a language implements some concept like parallel processing or arrays or control blocks, it's just for a moment until I get my bearings.
+ 4
For me I preferred to do it the Tesla way I get the program coded in my mind see all the default and place I will need help if I see no problem I try out the program in my mind see it running fine , than I can now sit and put it all into code , but I recommend this method to those who have already master the language , by the way carrying a notepad with chart of problem structure is a great way because you tend to add more to the creative of your program and it much easy to ask for help than a Guy who just does all in his mind with the power of imagination
+ 2
No, It is not a rule. You can have own ways to make things simple.
+ 2
I never found flowcharts useful as a design tool before writing code. It is less effort to write the code and correct it than to construct a flowchart and write the code. Back in the days of punch cards, paper tape and teletypes it was the other way around.
So where are flowcharts useful? Flowcharts are useful to pictorially communicate algorithms and system design structure to other developers and non-technical colleagues.
I find flowcharts are useful AFTER the code is written. I make a flowchart when I am analyzing undocumented legacy code. Having the quick reference has helped me be the hero a number of times when no one else could solve the company crisis. I saved several companies from untimely demise because I had taken the initiative to make legacy flowcharts. The charts pinpointed the problem sources, and helped the whole team to agree on the solutions when there was no time for trial and error.
0
I think if a program has certain complexity it helps to have a flowchart to visualize what you need to built and what the building blocks are.
If you need to built a completely new process for a company you get a design which usually consists of a flowchart and then you have to use it anyway to prove you build what was asked for.
There is a problem with flowcharts and programming though.
Flowcharts are schematic representations of a process and do not take into account the structured programming rules. A loop is not present and will be represented with a decision object pointing back to a previous object in the flowchart. But what about a forward loop? You need to create that by combining several decisions in a certain way (confusing).
Loops have certain demands in how to use them to prevent goto coding.
A loop should always be entered at the beginning and exited at the end of next object after the loop.
Flowcharts do not implement these rules and while logic seems to be okay in a flowchart while programming the process you might find that you can not translate the flowchart one-on-one thus leading to interpretation which might not result in a programm doing what was drawn in the flowchart.
Having said that. A flowchart is a great way to show very easily what a process is supposed to do and a very usefull tool to gain insight in what you want/need/have to deliver.