Similarly, make your methods short - really, really short. If you have 10 lines of code and put them each in their own method, great! Maybe it isnt the fastest code to read - but readable method names will make it obvious what each line does, and combining independent methods together is far easier than breaking one massive method into chunks.
I agree with a lot you said and this reads like advice straight from Robert Martins “Clean Code”, but I’ve recently read a discussion between him and John Ousterhout, where John makes compelling arguments for longer, “deeper” functions. I found the discussion very interesting and actually started reading “A Philosophy of Software Design” shortly after. Would recommend!
I think Ousterhout’s observation that deep interfaces are more useful is a very astute one. There is a kind of programmer who finds it satisfying to write lots of boilerplate but it doesn’t make the code maintainable.
Short functions can be good because you then name each short section of code, but a comment can offer that more flexibly.
I did feel like Ousterhout kind of undermined his own “comments go a long way in explaining code in longer functions” argument when his example code featured some incorrect comments, which is exactly what Martin warned about.
Honestly neither of them were really wrong anywhere, they just have a different approach. Sometimes I find Martins code split into too many functions, but halfway through there’s an example where Martins code is imo definitely clearer than Ousterhouts.
Both of their experience is valuable and is best shared, but not taken as gospel I think.
I agree with a lot you said and this reads like advice straight from Robert Martins “Clean Code”, but I’ve recently read a discussion between him and John Ousterhout, where John makes compelling arguments for longer, “deeper” functions. I found the discussion very interesting and actually started reading “A Philosophy of Software Design” shortly after. Would recommend!
I think Ousterhout’s observation that deep interfaces are more useful is a very astute one. There is a kind of programmer who finds it satisfying to write lots of boilerplate but it doesn’t make the code maintainable.
Short functions can be good because you then name each short section of code, but a comment can offer that more flexibly.
I did feel like Ousterhout kind of undermined his own “comments go a long way in explaining code in longer functions” argument when his example code featured some incorrect comments, which is exactly what Martin warned about.
Honestly neither of them were really wrong anywhere, they just have a different approach. Sometimes I find Martins code split into too many functions, but halfway through there’s an example where Martins code is imo definitely clearer than Ousterhouts.
Both of their experience is valuable and is best shared, but not taken as gospel I think.