When writing a (computer science) research paper, I have to describe my method in term in pseudocode. Because of readability and reusability, I want to break my method into smaller pieces. However, I don't know how to present them in my paper. As far as I know, there are two approaches:

  • Top-down: first, present a main pseudocode which calls/invokes other smaller ones which will be explained later.
  • Bottom-up: present and explain all the smaller pieces first, then combine them together into a bigger one.

For example, in my paper, I'm presenting a method to solve to a problem, this method is describe by a funtion, named SOLVE_PROBLEM, as follow:

    if CHECK(input) then:

As you can see, SOLVE_PROBLEM uses other functions (CHECK, FUNCTION_1 and FUNCTION_2) to find a solution. My question is to how to presents those functions in my paper. Should I present i) SOLVE_PROBLEM first (as it is the solution to the problem, which is the main point of the paper), or ii) other methods fisrt (as they are the building blocks to a solution)?

  • People read from top bottom, left -to-right in English. So, first SOLVE_PROBLEM, then CHECK, then FUNCTION_1 then FUNCTION_2
    – Alexandros
    Commented Jun 20, 2015 at 14:50
  • This seems to be a question about computer science, rather than about academia per se. Commented Jun 20, 2015 at 18:32
  • 1
    Whatever best communicates the algorithm to a human reader.(
    – keshlam
    Commented Jun 21, 2015 at 3:44

2 Answers 2


The answer depends on personal preferences, as well as on the algorithm itself. Consider the following two descriptions of SOLVE_PROBLEM:

Top-down: We want to solve problem A on input. Function SOLVE_PROBLEM solves the problem. There are two cases, depending on condition B, which we can check with function CHECK. If the condition holds, we solve the problem with FUNCTION_1. Otherwise we use FUNCTION_2.

Bottom-up: We want to solve problem A on input. In the general case, the problem can be solved with FUNCTION_1. The general solution assumes condition B, which we can check with function CHECK. If the condition does not hold, we can solve the special case with FUNCTION_2. This completes function SOLVE_PROBLEM.

I personally prefer the top-down approach, if the algorithm has multiple equally important parts. Bottom-up approach becomes preferable, if one part of the algorithm attacks the core of the problem, while the rest just deals with special cases and administrative stuff.


In general, you should avoid telling a reader something without justifying why you say it (in terms the reader already gets), to avoid frustrating his motivation. At the same time, the paper should be readable at least linearly, so you can't say too much about stuff you haven't presented yet.

To follow this guideline, it is often (but not always) better to proceed top-down. When you start, you've explained why readers should care about your problem, hence why you need SOLVE_PROBLEM. Then you present SOLVE_PROBLEM and explain what the different steps achieve (not the how). Hopefully names give a hint, but often it's not enough. SOLVE_PROBLEM in turn motivates the other procedures, so you can explain them in the same way.

With a bottom-up presentation, you risk presenting code without having justified why it's needed. Maybe your FuzzBahzz solver needs a BarBuzz solver which needs a BipBop solver, but readers who care about FuzzBahzz might not guess why BipBop is related.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .