Here is the best rendition i believe. See how regular the structure is. "Action" is the routine that actually does something.
You can nest as many loops as you need this same way and it is always very readable.

View attachment 203272

It may or may not be a very readable chart, but it is NOT the chart for the program code that was given in the first post.

Even if it executes Action the correct number of times for the exact values used in the code right now, it is not structurally correct. Change the limit on either loop from 5 to 0 and you will see.

 

okay thanks, Why the flow chart in post #17 is best and what's drawback in my last flow chart post #16

You cant see the difference?
#16 exits near the begining the C code exits at the end.
You can follow #17 the same way you follow the C code and it falls out at the bottom just like the C code.
Also, note that a statement like for(k;k<5;k++) does the increment at the END of the loop.

 

There is no one way to draw a flow chart.
One way is not better than another.
However, it is better to stick with a consistent structure.
See my blog on Structured Programming.

 

And the other thing:
Don't draw the flowchart to match the code. That is putting the carriage before the horse.
Draw the flowchart first.

It is like circuit design.
Don't build the circuit and then try to document the circuit with a diagram.
The circuit schematic comes before the circuit (and after the block diagram).
In other words:

Step 1 - Block Diagram
Step 2 - Circuit Diagram
Step 3 - Circuit

In programming:

Step 1 - Block Diagram
Step 2 - Flowchart
Step 3 - Code

 

I believe following are corrects flow chart

View attachment 203271

Although you've added "statement 1" and "statement 2" to this chart even though they aren't in your code, this is structurally fine. The thing that people have been trying to point out to you since the very first response is that they LAYOUT of your flowchart should be consistent. Consider the very minor changes I've made to the above chart:



You have a red loop and a green loop.

EACH loop has the same structure and layout that follows the "ITEM" pattern -- An (I)nitialization followed by an exit (T)est followed by an (E)xecute (loop body), followed by a (M)odify (increment). The loop body for the red loop is everything in the dashed red box. The green loop has exactly the same structure with the elements laid out in the same fashion.

Given a flowchart that follows this structure, it is very easy for someone to confidently code it up with very little change of error.

for (i = 0; i < 5; i++) // The "I", "T", and "M" elements for the red loop
{
   statement 1
   for (i = 0; i < 5; i++) // The "I", "T", and "M" elements for the green loop
   {
      statement 2
   }
}

The code in the braces for the red loop is exactly the portion of the flow chart in the dashed red box, namely "statement 1" followed by the green loop.

The code in the braces for the green loop is exactly the portion of the flow chart in the dashed green box, namely just "statement 2".

Note that I'm only showing the code that corresponds to the body of your main() program since you've indicated that you aren't including the header and return in the discussion.

As I stated in my first response, humans are very good at pattern recognition. If you draw your flowcharts in consistent patterns, people (including you) will find it MUCH easier to follow and the person that has to produce the code (including YOU) will find it MUCH faster and easier to do so and will be MUCH more likely to NOT make mistakes along the way -- plus any mistakes that do get made will be MUCH easier to track down and fix.

 

There is no one way to draw a flow chart.

My simple question is that does my flow chart #17 shows nested for loop? I just want to confirm. If it's not a nested loop then why not ?

 

My simple question is that does my flow chart #17 shows nested for loop? I just want to confirm. If it's not a nested loop then why not ?

Am I just pissing in the wind?

Assuming you are talking about your flow chart in Post #16, I've already said that structurally it is fine, that the issue is one of using a consistent layout.

The flowchart in Post #17 is NOT the same, it corresponds to nested do-while() loops, which are guaranteed to execute the loop body at least once. This is not the case for while() and for() loops.

 

It may or may not be a very readable chart, but it is NOT the chart for the program code that was given in the first post.

Even if it executes Action the correct number of times for the exact values used in the code right now, it is not structurally correct. Change the limit on either loop from 5 to 0 and you will see.

Yeah but his limits are never zero.
But if you like the way the other code looks go right ahead and use it
What you are suggesting is that there is a jump around the entire code body if the limit is such that it dictates that the body should never be executed, and that's right, but the chart is too messy in my opinion.
But ill take another look i think the 'fix' is simple and does not mess up the graphical appearance.

This might be more true to the functionality but i hate that the main body no longer appears to be top down.
I like that the inner and outer loops are still very apparent though and conditionals that are not true fall through very apparently top down.

 

Yeah but his limits are never zero.
But if you like the way the other code looks go right ahead and use it
What you are suggesting is that there is a jump around the entire code body if the limit is such that it dictates that the body should never be executed, and that's right, but the chart is too messy in my opinion.
But ill take another look i think the 'fix' is simple and does not mess up the graphical appearance.

How can you say that his limits are never zero? It is because they are constants in the snippet given? If that's the case, then just unroll the loops altogether and have a flow chart that does nothing but set i=5 and j=5 and be done with it.

The flow chart for a snippet code should look the same regardless of changes to specific parameters within the snippet. If you have to change the fundamentals of the flow chart just because someone changes the value of a constant in one expression, that means that the flow chart does not match that code snippet.

 

How can you say that his limits are never zero? It is because they are constants in the snippet given? If that's the case, then just unroll the loops altogether and have a flow chart that does nothing but set i=5 and j=5 and be done with it.

The flow chart for a snippet code should look the same regardless of changes to specific parameters within the snippet. If you have to change the fundamentals of the flow chart just because someone changes the value of a constant in one expression, that means that the flow chart does not match that code snippet.

Well thanks for the suggestions but first and foremost i did update the flow chart so take a look at the new one. It takes what you are saying into account so see i listen to your suggestions.

However, what you say might be true in theory but in practice i have found that flow charts ALWAYS match the application not some theoretical standard. I had to work extensively with these back in the 1970's when i had to create programs for precision weight scales. If there was no required zero case in the application then there was no zero case in the flow chart, it would be silly to add that just for the sake of theory.
So you are right in theory, but in practice it turns out quite different and if there was a zero case i might seriously consider initializing to -1 instead of 0 if it helped as there is nothing forcing us to initialize to 0 in practice either.

Overall i think this has been an interesting discussion.

 

There is no one way to draw a flow chart.
One way is not better than another.
However, it is better to stick with a consistent structure.
See my blog on Structured Programming.

Hi,

I agree there is no one way to draw a flow chart, but if you think one way is not better than another then you have not seen examples of purposely obfuscated C code. Sometimes people try to come up with the most obfuscated code possible just to see what it looks like and how hard it is to figure out sometimes. There are certainly better ways to write C code.
Ditto for a flow chart. I could create something so obscure that it would take you two days to figure out what it does even if it just increments a variable one time. This tells me that some ways are better than others.
Take a look at my new flow chart and see how simple and highly organized the layout is.

i am not bragging either someone may come up with an even better way and i'd like to see that and i would accept it as better tahn mine.

 

Well thanks for the suggestions but first and foremost i did update the flow chart so take a look at the new one. It takes what you are saying into account so see i listen to your suggestions.

However, what you say might be true in theory but in practice i have found that flow charts ALWAYS match the application not some theoretical standard. I had to work extensively with these back in the 1970's when i had to create programs for precision weight scales. If there was no required zero case in the application then there was no zero case in the flow chart, it would be silly to add that just for the sake of theory.
So you are right in theory, but in practice it turns out quite different and if there was a zero case i might seriously consider initializing to -1 instead of 0 if it helped as there is nothing forcing us to initialize to 0 in practice either.

Overall i think this has been an interesting discussion.

Keep in mind that here the "application" that the TS is working with is for the flowchart to match the code snippet.

 

Well thanks for the suggestions but first and foremost i did update the flow chart so take a look at the new one. It takes what you are saying into account so see i listen to your suggestions.

Is this the one you are talking about:


Presumably this is supposed to match the code:

for (i = 0; i < 5; i++)
{
   for (j = 0; j < 5; j++)
   {
      Action();
   }
}

So what if Action() prints out the sum of i and j?

What is the first thing that is output by the actual code?

What is the first thing that is output by your flowchart?

Or is this a case of, "Well, IF the Action actually needed the value that j actually had when the actual code is run, we'd come up with yet a different flowchart for the same code snippet."

Why is it such a terrible thing to have the flowchart for a snippet of code actually match the logic of the code?

Again, humans are very good at pattern recognition, even when it works against us. We expect flowcharts to flow from top to bottom. So when we see a box with "Action" in it immediately above a box with "j++" in it our minds automatically peg the order in which these two tasks are carried out as being first "Action" and then "j++". But because you have these logic tasks in an upward flowing branch of the flow chart, that ingrained pattern matching ability results in people seeing something that is not there.

 

Yes i drew that section upside down. I corrected it but fell asleep before uploading.
Good catch though.

 

But do you see my point? The reason that you made the mistake and, furthermore, didn't immediately catch it, is because you drew a section of the logic upside down, thus going against the natural pattern recognition abilities that humans have and instinctively use.

If you hand that flowchart off to a bunch of coders, there will be some fraction of them that will implement the code on that branch in the reverse order for the exact same reason.

Why set them up for failure like that?

What is so bad about giving them something that matches the code structures they are going to use?

 

No i just drew it too fast.
You really think that loop de loop de loop is better? Wow.

 

No i just drew it too fast.
You really think that loop de loop de loop is better? Wow.

It would be interesting to put it to the test. Take a couple of programs (perhaps something on the size of a typical programming assignment midway through a first C course) and prepare two flowcharts for each, one in each style. Then randomly have about 1/4 of the students code each of the combinations one day and a week or so later program the other program using the other style. Measure how long it takes to code the program and how well it gets coded. I'd even be interested in how many times the program had to be compiled before it was correct.

 

It would be interesting to put it to the test. Take a couple of programs (perhaps something on the size of a typical programming assignment midway through a first C course) and prepare two flowcharts for each, one in each style. Then randomly have about 1/4 of the students code each of the combinations one day and a week or so later program the other program using the other style. Measure how long it takes to code the program and how well it gets coded. I'd even be interested in how many times the program had to be compiled before it was correct.

Yes that would be interesting.

I guess what i am going by is what we might call the highest entropy drawing based maybe on how much ink it takes to make the drawings, given equal width lines and same size blocks and same font and same wording and variable names and such, and reasonable block spacing, for all drawings. The one made with the least volume of ink wins, which i guess implies the shortest connecting lines too.
Maybe more to the point is a drawing that you dont have to follow lines around the page like a city map of downtown New York City.
I think the simplest representation wins.

 

Yes that would be interesting.

I guess what i am going by is what we might call the highest entropy drawing based maybe on how much ink it takes to make the drawings, given equal width lines and same size blocks and same font and same wording and variable names and such, and reasonable block spacing, for all drawings. The one made with the least volume of ink wins, which i guess implies the shortest connecting lines too.
Maybe more to the point is a drawing that you dont have to follow lines around the page like a city map of downtown New York City.
I think the simplest representation wins.

By that line of reasoning, then if I were to prepare turn by turn directions for you to get from your house to some place you wanted to go and then used a compression algorithm that reduced it to 10% of the number of bits would you prefer to have the compressed bits, or the original text with all of the inefficiencies and redundancies that go along with the English language? Simplest representation doesn't always win. In a context like this, I would think that the representation that is the most direct match to what is being represented is more valuable.

 

By that line of reasoning, then if I were to prepare turn by turn directions for you to get from your house to some place you wanted to go and then used a compression algorithm that reduced it to 10% of the number of bits would you prefer to have the compressed bits, or the original text with all of the inefficiencies and redundancies that go along with the English language? Simplest representation doesn't always win. In a context like this, I would think that the representation that is the most direct match to what is being represented is more valuable.

Well yes sometimes there are other criteria that have to be met.
Most people prefer the simplest route from home to the grocery store (or anywhere else too) but i took the back roads more often because there was less traffic and it was overall a safer route. But then the town started neglecting the road surfaces not fixing them so the back roads are very bad now. So now i take the main roads more often too, with less turns and stop signs.
So there i even had to switch gears due to changing environment.