Hacker News new | ask | show | jobs
by Murk 3479 days ago
I don't agree entirely with what the article says because it can be a problem to have to sift though a lot of small functions in order to determine what is going on. Sometimes, I think it's easier to read a moderately sized, but "clean" function that you can read from top to bottom, rather than a spiders web of references to other functions which may contain the nuance or bug you are looking for. What he has said reminds me of what the Forth community necessarily espouse, though.

People tend to take the length guidelines far too seriously though. Instead it requires thought and experience. The main Principe I try to follow is make it readable, it doesn't matter how it's written or if you've decided to use a goto in there, so long as it is one of the more readable alternatives.

2 comments

There is a less chance to have a bug in a very small function than moderately sized, but "clean" function.

It is also easier to write a test for a smaller function.

Having the implementation in many smaller functions also makes the code more readable if their naming is good.

> There is a less chance to have a bug in a very small function than moderately sized, but "clean" function.

Maybe so. But you need several of the very small functions to do the same work as the moderately sized function, and those several very small functions have to interact with each other. So did the total chance of a bug go up or down? It's not clear, but I lean toward the one moderately-sized function being more likely to be bug-free.

I think realistically in many cases the buggedness will still favour many smaller functions - if for no other reason than they must all be named.

The higher level function is then easy to read. The lower level functions get a name that can be checked more easily against an implementation if needed.

readability is just one small piece of the reason why keep one function does one thing. Understanding how to make your code SOLID is very important.

After all, software development is still a engineering process, in which personal coding style is far less important.