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;


    // do A

    // do B

    // do C

I write it like this


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)


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'?

  • Good question. I'd also prefer your variant, but have no real argument for it. – user188153 Dec 31 '16 at 17:26
  • 3
    1. This is a conversation that you should also be having with your other engineers. 2. Your example is too abstract to do anything with except make general observations about function calls. Can you provide a more specific example that is grounded in the actual problem domain? – Robert Harvey Dec 31 '16 at 17:42
  • The two samples are not equivalent in that the latter does not pass the parameters (e.g. to B). Perhaps that is that an omission or maybe you are suggesting something. Also, what does the error handling / error path look like in the two different approaches? These are some reasons more content/context is needed for a quality answer. – Erik Eidt Dec 31 '16 at 23:47
  • @ErikEidt parameter are an optional detail. I neglected to put it in the 2nd example – Gusdor Jan 1 '17 at 0:18
  • It has probably more to do with how the problem was presented than a specific C developer mindset. – Patrick Schlüter Jan 17 '17 at 13:42

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!

  • This is bad style in C too, especially embedded C where you don't have stack space to burn. – Karl Bielefeldt Dec 31 '16 at 20:41
  • I agree one hundred percent. I am not defending their style; a lot of code gets written in bad style. – Doug Dec 31 '16 at 20:50
  • This is bad advice overall. If you're hiring C developers for C# work, it's their responsibility to learn C# idioms, not continue to do things the way they've always done them. The "don't be a jerk" at the end of your post is inexplicable. – Robert Harvey Dec 31 '16 at 22:57
  • 1
    According to the OP, the C developers were transitioned to C#. It IS their job to LEARN, and it is his job to show them without belittling them. Do you like someone to be a jerk to you when you start a new job? – Doug Dec 31 '16 at 23:19
  • @Doug 'Don't be a jerk' is something I am working on but I have been very 'softly softly' with these particular colleagues so far. I want to encourage them, not scare them. – Gusdor Jan 17 '17 at 13:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.