Chaining functions in procedural languages

Question

My department is about to make some new hires. They are likely to be a) junior or b) more experienced that myself.

This year I have helped some C engineers transition to C# and observed some interesting code structure being written. I wish to learn more about why they are doing it, if I should encourage 'my way' and what the pros and cons of each are.

The problem

Lets assume Some Process with 4 steps, A > B > C > D.

The C engineers have been writing it like this;

SomeProcess()
{
    A();
}

A()
{
    // do A
    B(parameters);
}

B()
{
    // do B
    C(parameters);
}

C()
{
    // do C
    D(parameters);
}

I write it like this

SomeProcess()
{
    A();
    B();
    C();
    D();
}

The reinforcement I have for 'my way' is this:

1. It is clearer what is happening as the code reflects the documentation
2. The stack is smaller
3. The top level composition allows the functions to be used in other processes, e.g A > C > B
4. If the process has a return value, I can change the return type in only a few lines (this is pretty minor)

Question

I wish to present some objective learning in this area.

Why would the other engineers be writing this structure? Are there any downsides to 'my way'?

Answer 1

I've worked with C developers that write code like your example. From my experience, they are more used to writing code with global variables and buffers, so it is logical for them to write code like that. While your example isn't recursive, I could see some one writing a set of recursive methods/functions like that.

I will note that most C developers will write in other languages like they code in C, so it is a hard habit to break for someone who has been writing C for over 20+ years.

The chances of chance of changing their style are slim to none, but I would try to institute regular code reviews and maybe a weekly or bi-weekly session to throw out examples on how you or others solved particular problems. This has helped me in the past and would probably help your new hires.

Don't be a jerk!