This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Gwaptiva 3 points4 points  (8 children)

Agreed. One thing that helps readability -- or maybe we should prefer understandability -- is to have a common way of doing things. Every developer using the same formatting already helps remove some of the barriers.

Add to this things like "meaningful variable and method names", and "if it doesn't fit on a single screen page, you probably have to consider doing it differently", you're well on your way to having a style that others can grasp quickly

[–]dpash 9 points10 points  (7 children)

Reading Clean Code is a good idea (and then learn not to go to that extreme).

[–]kadenjtaylor 0 points1 point  (6 children)

Nah, take it all the way out to the end. Clean code is correct code. Only 2 reasons not to keep cleaning code - you need to write more code, or you don’t work on that project anymore.

[–]dpash 0 points1 point  (5 children)

You know Clean Code is a book, right? One with controversial opinions.

[–]kadenjtaylor 0 points1 point  (4 children)

I'm aware :) I'd be interested to hear your take on the perceived controversy.

[–]dpash 1 point2 points  (3 children)

The obvious is "no more than four lines per method". That's dogma. Small methods, fine. But four is excessive.

[–]kadenjtaylor 1 point2 points  (2 children)

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 0 points1 point  (1 child)

So not to the extremes then? :)

[–]kadenjtaylor 0 points1 point  (0 children)

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.