There are a few things to discuss when we talk about the
The very first one is the shape of the decision block. A traditionally recommended shape is a diamond. The diamond shape probably works just fine if a condition is very short. In practice, however, a lot of code has complicated and quite often multilined conditions which are hard to squeeze into a reasonably sized diamond. The diamond will either occupy too much space on the screen or the font size will be too small if readable at all. So my suggestion is to use compromise graphics which have the left and right edges resembling a diamond with the top and bottom edges flat to better use the screen pixel estate. That shape can be easily and naturally scaled to accommodate a condition of an arbitrary complexity.
The second thing to discuss is how to draw the
no branches. One of the alternatives here would be to draw them as shoulders
on the left and right of a decision block. However, this may lead to a diagram which is hard
to read and which does not look nice. The problem comes from the fact that the branches may have
arbitrary complexity and in graphics it may lead to very wide shoulders. Consequently it may make
browsing the diagram inconvenient because both, the vertical and horizontal scrolling would be required.
The other consideration is a thing which I call a main line of execution. Imagine that you are working with a code which you are not familiar with. Your natural wish would be to follow what the program main purpose is and then investigate error handling, special cases etc. It would be nice if on graphics the main line of execution goes always on the most left hand side and preferably in terms of positive logic. To emphasize the main line of execution on graphics I decided to locate the branches as shown on the example, i.e. one branch is located beneath the decision block and the other branch always grows to the right.