An overview of the science on function length

Re:An overview of the science on function length by freetime2 on Monday August 31, 2020 @05:58AM (#24329872)

I find that a lot of junior developers tend to go overboard with creating small functions, and the motivation is largely aesthetic. They have a mental image of what “clean” code is supposed to look like, and it doesn’t involve lots of indentation, curly braces, mathematical notation, etc. So they often try to bury these messy details inside a function.

They don’t have a lot of experience reading and debugging other peoples’ code, so they might not consider how much of a pain it can be to have to go jumping through a whole bunch of deeply nested one or two-liner functions just to see what the code actually does.

[ Parent | on HN ]

Re:An overview of the science on function length by CuriouslyC on Monday August 31, 2020 @08:42AM (#24330834)

Small functions are a form of semantic annotation when used properly.

If I'm working with code that modifies an image, I'd much rather see "rotate" than a matrix multiply. Heck, if I'm dividing a number by some special value, say to normalize it, I'd prefer to see "normalize" than a mystery division. I do agree that I'd rather see x + 1 than "addOne" though, since that doesn't tell me anything the code itself didn't.

[ Parent | on HN ]

Re:An overview of the science on function length by freetime2 on Monday August 31, 2020 @06:48PM (#24336649)

If a block of code is short (a few lines or less), and doesn't get reused in multiple places, I often prefer to add a clarifying comment rather than extracting the code out into a separate function. That way they reader doesn't need to go jumping around to see what the code does. And you can fit more information on a comment line than you can in aSuperDuperDescriptiveFunctionName.

[ Parent | on HN ]

Re:An overview of the science on function length by klyrs on Monday August 31, 2020 @08:46AM (#24330867)

> "... if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." - Linus Torvalds

I've had that quote thrown at me by a petty reviewer. Okay advice in C, utter shitshow in python classes. Like pep8 and Dijkstra's rant on goto, it's generic advice, not a holy mandate.

[ Parent | on HN ]

Re:An overview of the science on function length by besulzbach on Tuesday September 01, 2020 @12:00PM (#24343218)

I agree. I am most annoyed by the use of maxims with something so subjective and context-sensitive as code. I've read and written code with 4 (and maybe even more) levels of indentation that made complete sense and code with 2 levels that should probably be refactored into only having one.

I've seen people propose things as dubious as a character limit per function body. Most programming languages are so flexible that no matter what guidelines you set for your project, there will still be very bad code that conforms to all of them.

Forcing function splitting by rules is a good example of this. Very large functions are probably doing too much, but where and how you split them matters incomparably more than if you split them at all.

[ Parent | on HN ]