4 ms·

IMHO the "casual" reader should be able to understand the body of one function in isolation ; i.e, she shouldn't need to to dig through other functions (caller

by Ace17 8y ago

IMHO the "casual" reader should be able to understand the body of one function in isolation ; i.e, she shouldn't need to to dig through other functions (callers/callees). This is exactly why all functions should be kept small, and thus it might be preferable to extract small functions. Proper function naming is critical here, but it works : when was the last time you needed to look at printf's source code to understand your own code? Same thing for max/fopen/malloc/atoi/scanf/sqrt ... if it works for standard library's functions, we can make it work for our own functions.

danmaz74 8y ago
Standard library functions are well understood because they are shared between all projects using a language. Their naming doesn't even need to be descriptive, because people will learn them regardless. But functions which only exist in your project are a completely different beast. It is often very difficult to capture what they do in the name, even when you try to - especially for the higher level functions, which do a whole lot of things (by calling other functions). And, even if the name was originally good, it could become misleading when new use cases are added later - I found this problem very often when working on legacy codebases. Using lots of small functions isn't a panacea, and is completely different from functions in the standard library.
- speedplane 8y ago
  A good anecdote about this: I once wrote a file_lock function for a company that took about 15 minutes to complete. The function name was something like "file_lock". But then, it had to be modified to work on Mac and Windows. Then again, had to double re-entrance from the same thread. Again, it had to be modified to lock files for network files, FTP files, you name it. I worked on that initially tiny function on and off for two years. Anyone just reading the function title and comments along the way could easily assume it did things that it didn't.

by Ace17 8y ago

danmaz74 8y ago

Standard library functions are well understood because they are shared between all projects using a language. Their naming doesn't even need to be descriptive, because people will learn them regardless. But functions which only exist in your project are a completely different beast. It is often very difficult to capture what they do in the name, even when you try to - especially for the higher level functions, which do a whole lot of things (by calling other functions). And, even if the name was originally good, it could become misleading when new use cases are added later - I found this problem very often when working on legacy codebases. Using lots of small functions isn't a panacea, and is completely different from functions in the standard library.

speedplane 8y ago
A good anecdote about this: I once wrote a file_lock function for a company that took about 15 minutes to complete. The function name was something like "file_lock". But then, it had to be modified to work on Mac and Windows. Then again, had to double re-entrance from the same thread. Again, it had to be modified to lock files for network files, FTP files, you name it. I worked on that initially tiny function on and off for two years. Anyone just reading the function title and comments along the way could easily assume it did things that it didn't.