8 ms·

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 goin

by Murk 10y 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.

mishkovski 10y ago
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.
- AnimalMuppet 10y ago
  > 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.
  - spronkey 10y ago
    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.
stevesun21 10y ago
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.

by Murk 10y ago

mishkovski 10y ago

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.

AnimalMuppet 10y ago
> 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.
- spronkey 10y ago
  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.

stevesun21 10y ago

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.