[collyw]

I was thinking about this recently, and wondered how other people think of this. Working in a high level language like Python, you can do quite a lot in one line, for example in a list comprehension.

Should a "productive" one liner be put in a separate method / function with meaningful name, or better a comment beside it?

I personally find short methods often decrease code readability, as you constantly have to jump around, and can't read anything from top to bottom.

[Robin_Message]

> I personally find short methods often decrease code readability, as you constantly have to jump around, and can't read anything from top to bottom.

In general, if you have to jump into every method call to understand a method that calls other methods, the names are bad – probably too short and don't state intention.

[peterwaller]

My approach is frequently to "name" a complicated list comprehension by shoving it into a one or two-liner closure function in the current scope. Then you don't have to jump miles and the code which uses it becomes readable.

[collyw]

So what is the advantage of this approach over having a comment beside it? Sounds slightly more complex to me.

[peterwaller]

Because comments can lie.

Also, it can be harder to express the generator in a useful way in English than the code itself if the code is well written.

The purpose is to make the code as clearly self describing as possible. I would only do it if it made the code read more like a human language and remove too much complexity from one place.

[henrik_w]

Well named short methods lets you read the code on a higher abstraction level. I usually jump into methods to see what they do the first time I encounter them. Later on, the name (if well named) should tell me what it does, so I don't have to wade through the details of how it does it. That's part of what I'm getting at in "7 Ways More Methods Can Improve Your Program" http://henrikwarne.com/2013/08/31/7-ways-more-methods-can-im...

[marcosdumay]

Well, I can really say what it should be...

But I put one-liners in a function when the one-liner is hard to read or too error prone (missing a detail won't lead to a compiler error, but to a bug).