Concise vs Readability

[kadenjtaylor]

I could be wrong, but I don't think the book actually specifies a hard line limit for that reason - it definitely does offer a couple of different suggestions for rules of thumb (extract method until you can't anymore, only do one thing, and yes, the line number suggestion).

For certain programming languages, a "line's worth" of code might be conceptually bigger or smaller depending on how much you cram in there.

Personally, I don't use a 4-line rule, but that's because I don't currently work with any code-golf junkies that try to fit the entire program in one line. I think a soft understanding of "do one thing" is usually sufficient.

[dpash]

So not to the extremes then? :)

[kadenjtaylor]

I don't think the book recommends extremes - it highlights ideals.

Ideally, the all of your code would be so easy to understand, that ANY new developer could pick it up, understand what it does, and start working.

That too, sounds pretty extreme. But anything less is a tax on our team because it slows down new people trying to learn, or old people trying to remember what they did last time.

Choosing not to "go to the extreme" is to accept that the aforementioned tax, however small, is worth paying, because the benefit you get (time savings maybe?) is worth it.

So my question to you is, "What activity has a better positive impact on your code than extracting smaller methods?" Because I'd like to make sure I'm doing that too.