4 ms·

How does everyone feel about the last item, the "seven lines per function rule"? I can definitely appreciate the readability of this assuming the functions and

by FLGMwt 11y ago

How does everyone feel about the last item, the "seven lines per function rule"? I can definitely appreciate the readability of this assuming the functions and intermediate variables are well named, but am I the only one that fears negative PR feedback about adding cruft?

ShaneWilton 11y ago
"but am I the only one that fears negative PR feedback about adding cruft?" Go for it, and you might be surprised as how your team responds. The biggest improvements to our codebase have come from my colleagues making controversial changes. Sometimes they don't get merged, but sometimes they end up shaping how we write code going forward. You should never be scared of negative PR feedback -- your reviewers aren't judging you, they're judging your code, and code responds surprisingly well to criticism.
simoncion 11y ago
> How does everyone feel about the last item, the "seven lines per function rule"? As with all constructs that incorporate magic numbers, I really, rather dislike it. Playing "follow the function call trail" can be just as harmful to code readability as overly-long functions. I do strive to write functions that are as short as is reasonable, and I do lift single-use code blocks out into their own functions when doing so improves clarity. However, I'm neither an English 101 student, nor a newspaper journalist: I don't stress about whether my work meets some arbitrary length criteria. :)
- kybernetikos 11y ago
  It's amazing how people seem to miss that sending their readers jumping around all over the place just to get an idea of what is going on can be worse than long functions where the code reads coherently and simply. I think Clean Code has encouraged people to write a lot of single line functions that get called from a single place (often with weird parameter lists) as a means of replacing commented code blocks. While it has its place, this is not a good pattern in general. Good function writing is similar to what gets said for objects in OO design. The function should do one cohesive thing that it is sensible to give a name to and consider at least somewhat in isolation from its context. It should take in a relatively small number of parameters (external dependencies for classes), all of which should be the sorts of things you'd expect it to need from its name.
  - simoncion 11y ago
    > I think Clean Code has encouraged people to write a lot of single line functions that get called from a single place (often with weird parameter lists) as a means of replacing commented code blocks. Single line functions, called from a single place? To replace commented code blocks?? In the name of improving readability!? What?! (!!!) Unrelated to that: If your function name correctly and completely describes the actions taken by that function and those that it calls, then replacing a commented code block with that function isn't unreasonable. shrug I guess the ages old advice: "Dogma is bad. Rules of thumb are often useful." applies to the topics discussed in this subthread. :)
rdtsc 11y ago
Short functions is a pretty universal and good heuristic. Breaking things down in smaller easier to understand pieces if you can applies to any language probably. 7 lines is just a heuristic.
- LunaSea 11y ago
  It really isn't. As another user said below, following long function call chains is counter-productive and if you don't have an ultra strict function naming policy you will have functions with duplicate functionalities very quickly.
  - rdtsc 11y ago
    > following long function call chains is counter-productive Well, be productive then! It is a heuristic. I don't think I am in the minority saying that "breaking things down in small manageable chunks is a good thing". That's is not just Erlang that's common sense. That's the point. That doesn't mean having to count lines if you go over 7 start making functions like next1 next2 and so on. That's called being pedantic.
    - LunaSea 11y ago
      No being pedantic is giving a fixed number. Just say: "try to keep functions small" and be done with it without needing to debate semantics.
wetmore 11y ago
I just said this somewhere else, but if you change it to ten lines per function you can rearrange FUCRS and then you'll really be adding CRUFT.

by FLGMwt 11y ago

ShaneWilton 11y ago

"but am I the only one that fears negative PR feedback about adding cruft?" Go for it, and you might be surprised as how your team responds. The biggest improvements to our codebase have come from my colleagues making controversial changes. Sometimes they don't get merged, but sometimes they end up shaping how we write code going forward. You should never be scared of negative PR feedback -- your reviewers aren't judging you, they're judging your code, and code responds surprisingly well to criticism.

simoncion 11y ago

> How does everyone feel about the last item, the "seven lines per function rule"? As with all constructs that incorporate magic numbers, I really, rather dislike it. Playing "follow the function call trail" can be just as harmful to code readability as overly-long functions. I do strive to write functions that are as short as is reasonable, and I do lift single-use code blocks out into their own functions when doing so improves clarity. However, I'm neither an English 101 student, nor a newspaper journalist: I don't stress about whether my work meets some arbitrary length criteria. :)

kybernetikos 11y ago
It's amazing how people seem to miss that sending their readers jumping around all over the place just to get an idea of what is going on can be worse than long functions where the code reads coherently and simply. I think Clean Code has encouraged people to write a lot of single line functions that get called from a single place (often with weird parameter lists) as a means of replacing commented code blocks. While it has its place, this is not a good pattern in general. Good function writing is similar to what gets said for objects in OO design. The function should do one cohesive thing that it is sensible to give a name to and consider at least somewhat in isolation from its context. It should take in a relatively small number of parameters (external dependencies for classes), all of which should be the sorts of things you'd expect it to need from its name.
- simoncion 11y ago
  > I think Clean Code has encouraged people to write a lot of single line functions that get called from a single place (often with weird parameter lists) as a means of replacing commented code blocks. Single line functions, called from a single place? To replace commented code blocks?? In the name of improving readability!? What?! (!!!) Unrelated to that: If your function name correctly and completely describes the actions taken by that function and those that it calls, then replacing a commented code block with that function isn't unreasonable. shrug I guess the ages old advice: "Dogma is bad. Rules of thumb are often useful." applies to the topics discussed in this subthread. :)

rdtsc 11y ago

Short functions is a pretty universal and good heuristic. Breaking things down in smaller easier to understand pieces if you can applies to any language probably. 7 lines is just a heuristic.

LunaSea 11y ago
It really isn't. As another user said below, following long function call chains is counter-productive and if you don't have an ultra strict function naming policy you will have functions with duplicate functionalities very quickly.
- rdtsc 11y ago
  > following long function call chains is counter-productive Well, be productive then! It is a heuristic. I don't think I am in the minority saying that "breaking things down in small manageable chunks is a good thing". That's is not just Erlang that's common sense. That's the point. That doesn't mean having to count lines if you go over 7 start making functions like next1 next2 and so on. That's called being pedantic.
  - LunaSea 11y ago
    No being pedantic is giving a fixed number. Just say: "try to keep functions small" and be done with it without needing to debate semantics.

wetmore 11y ago

I just said this somewhere else, but if you change it to ten lines per function you can rearrange FUCRS and then you'll really be adding CRUFT.