3 ms·

I love when developers make food analogies, they almost always show their ignorance of cooking, and sometimes of software development. After 30+ years of softw

I love when developers make food analogies, they almost always show their ignorance of cooking, and sometimes of software development. After 30+ years of software development, I always read the actual code to find out how software works. "CombineIngredients" is useless and honestly quite horrific. Instead of "simplifying" it is obfuscating. The details of cooking are in the function. I don't need to see "PreheatOven" at the same level as "CombineIngredients". One of my favorite posts on this subject is: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Tucking away code in a function serves a purpose, and that purpose is not to make the highest level function hold no detail. Like cooking, software is about the details, so don't hide them from me. I can't stand the "Russian Doll" approach of a function that just calls another function that just calls another function that just ... Nothing improves the understandability of 10 lines of code than spreading it across a 10 functions often in different files /s Great abstractions exist, but very few abstractions are great.

Bekwnn 8y ago
In my experience Unreal Engine 4 suffers from this. It's a fantastic game engine and in many ways its code is really great, but on many of the occasions when I've had to trace call stacks in its source, it's a mess of long function call chains marred with branching conditions and extremely similar sounding function names. I think it's a good example of how code can look clean but actually be a bit of a mess to work with. In contrast at my job I've been making heavy use of structs and functions scoped solely to cpp files. The result has been in my experience somewhat messy-looking code which actually has very low cognitive overhead and is very easy to change. Sometimes long functions are a viable answer. It all depends on whether it actually makes sense to tear things out, otherwise that function called in only one place you pulled out is just polluting the scope. There are other ways to handle it: local function, placing the chunk of code in its own scope limiter, and possibly comments documenting and breaking down the steps.
charleslmunger 8y ago
Yes. For many codebases, the primary purpose of the source code is being read by humans with the goal of understanding its actual behavior. When I'm reading through a codebase obfuscated by single-use helper functions, the first thing I do is inline them all. Bugs often result from the software doing something different from what its author intended, so the human-authored function name is not a substitute for reading its implementation.

Bekwnn 8y ago

In my experience Unreal Engine 4 suffers from this. It's a fantastic game engine and in many ways its code is really great, but on many of the occasions when I've had to trace call stacks in its source, it's a mess of long function call chains marred with branching conditions and extremely similar sounding function names. I think it's a good example of how code can look clean but actually be a bit of a mess to work with. In contrast at my job I've been making heavy use of structs and functions scoped solely to cpp files. The result has been in my experience somewhat messy-looking code which actually has very low cognitive overhead and is very easy to change. Sometimes long functions are a viable answer. It all depends on whether it actually makes sense to tear things out, otherwise that function called in only one place you pulled out is just polluting the scope. There are other ways to handle it: local function, placing the chunk of code in its own scope limiter, and possibly comments documenting and breaking down the steps.

charleslmunger 8y ago

Yes. For many codebases, the primary purpose of the source code is being read by humans with the goal of understanding its actual behavior. When I'm reading through a codebase obfuscated by single-use helper functions, the first thing I do is inline them all. Bugs often result from the software doing something different from what its author intended, so the human-authored function name is not a substitute for reading its implementation.