I tried creating a flow chart of a function that I use in my program, but there are a lot of conditional statements in between every process and the diagrams are getting more confusing.

Is there a another language or markup other than flow charts that can be employed for large codebases with high complexity?

  • If you have some sample code to post on codereview.stackexchange.com, I'm sure those folks would be more than happy to provide some suggestions for simplifying it. Commented Aug 22, 2011 at 22:12
  • This is a good indication that perhaps you should learn to manage that complexity. Tip: use very short functions.
    – Job
    Commented Aug 22, 2011 at 22:22
  • linked sub-diagrams, if you must create a flow chart. sequence diagrams and action diagrams are better. data-flow diagrams are useful also. if it won't fit on a page, break it down Commented Aug 23, 2011 at 7:08

5 Answers 5


If the flowchart for one function is so complex that it is difficult to understand, then the function is too complex. Consider the Refactoring pattern called "Extract Method." (It can be used on non-OO procedural functions too.)


Use nested layers of DFD

Generally the best way to tackle complexity in any software system is to simplify it. One of the better ways that I have found to simpify diagramming complex software is to break it up into layers with differing granularity of concept.

For Example

Diagram 1 has a very top down highest level overview of your system. This almost doesn't have any real logic behind it more that it outlines how your highest level systems hang together. If you wish to see how a particular system works you look at another diagram.

Diagram A goes into more detail about how System 1 works, however once again this is a high level overview and outlines how system 1 works conceptually, however actual logic is referred to futher sub diagrams.

At the lowest granularity this is where the actual logic for the system comes into play and so like object inheritence in code (assuming you're using OOP/OOD) you have multiple levels of abstraction in your DFD as you do in your code and so the actual implementation details are delegated to your finest granularity of objects.

Cognitive complexity

However at each layer there should be rules regarding cognitive complexity. Like code your diagrams should be able to be understood easily within 5 minutes or less.

Well designed code should also follow the above rules for cognitive complexity

Generally this is how your code should be layed out as well, well designed code should also be easily understood within 5 minutes or less.

  • data-flow diagrams are not very good for showing conditional logic steps, which seemed to be the OP's intention. good answer in general though! Commented Aug 23, 2011 at 7:06

If your code logic is complex because it has too many conditions, flow charts don't help. The better approach is to use Pseudocode to describe your logic. find details about Pseudocode here: http://en.wikipedia.org/wiki/Pseudocode also

if you want to show table relationships, then you use Entity Relationship Diagrams, and if you want to show process dependencies you use BPM. Each diagram has a purpose and limitations.


Scitools Understand are good at creating graphs regarding program dependencies (functions, subroutines and so on) for several main languages. I don't think they have flowcharts, but you can always divide your complex code into functions (which you should do to some point, nevertheless) and that should make it more maintainable.

What languages are you aiming at with this?

enter image description here


You can try to create sequence diagram (OO design) in order to make the message flow clear among different instances/components.