1.4 Middle Checking Loop
You will notice a symbol you haven’t seen before in the image on the left. This is the symbol that once meant tape input. Many drawing programs, including the one I’m using, now use it to indicate sequential data.
Pay attention to the dashed lines running from the tape symbol to the IO symbols. There are a lot of different rules about this, depending on where you go. Some places want the dashed line to have no arrow heads. Some only want dashed lines to the open and close. They mandate you put the actual record name in the other IO symbols. I don’t really like the file symbol to appear at all when working at this level. When laying out the flow for an actual program, we used to create a data legend page that contained the disk drive symbol, name of the file, organization of file, keys and method of access (read, write, update or delete). Each file would be given some hokey little code like #1, #2, #3, etc. Because the symbols were small, we would use the codes inside of the symbols. When we were drawing flowcharts for BASIC programs the numbers directly corresponded to the channel numbers we would use in the programs.
Take a close look at the above diagram. Where do I ever set EOF to TRUE? The answer is I don’t. The error handling wrapped into the IO operation is going to set that value for us. You probably do not know enough about software development to fully understand that statement, so let me explain. Every language I’ve ever worked with (higher in the food chain than Assembler) provides some method of built in IO exception trapping. I’ve encountered people in the past who demanded you show this in the flowchart. Going to that level really is a bit much. COBOL has an AT END clause on its read statement. BASIC tosses BASIC ERROR 11. C provides the feof() function so you don’t even declare the EOF variable we used in this diagram. Most developers are smart enough to understand EOF means End of File. If you have more than one file use something like EOF_name or EOF_#2.
Take a look at my decision symbol in this diagram. I didn’t label the branches. Most instructors will slap you pretty hard for that. Many instructors want you to put simply EOF in the decision symbol then label the branches TRUE and FALSE. It will be up to your instructor to set the ground rules. My focus is getting you to visualize the logic you need. The finer details about drawing it don’t interest me that much. As long as you can see it in your mind, you will be able to code it when you move onto programming.
When it comes to the middle checking loop, most academics will hiss, cluck their tongues and call it bad design. Those people have never worked in the real world for a living. A middle checking loop is forced on us by language limitations involving IO. If you want to make a politically correct loop that checks at the top, then you have to code up two IO calls along with their complete sets of error handling. The first one is executed only one time before entering the loop, and the last one is executed at the very bottom of the loop. I have coded it both ways in my professional life. The rules of the shop you work at will force the decision on you.
Take a look at the above diagram. If we made it a purist bottom checking loop, we would have to add one more IO symbol after “do something.” Then we would have to find a way to get the dashed line from the sequential data symbol over to it, or we would have to make an additional copy of the sequential data symbol. Either way, a little bitty loop would start to get messy.
You are now beginning to understand why every programmer must cut their teeth with flowcharting. While it is technically true that you won’t physically draw a program flowchart in the real world, you will draw little pieces in your mind as you are writing.