3 ms·

I'm disappointed to see this is still the top comment, for a few reasons. 1) Lines longer than 80 are an indicator that your code is getting too verbose, at le

by d23 13y ago

I'm disappointed to see this is still the top comment, for a few reasons. 1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. 2) You should be taking the time to figure out how to maximize readability of your code. And breaking the lines is damn near instantaneous when compared to the time taken to pick a good variable name or decide on overall design structure. 3) Not everyone will have the same editor. Your code should stand on its own and be readable in its own right.

baddox 13y ago
> 1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. I completely disagree, partly because I prefer to err on the side of verboseness, and partly because 80 is just ridiculously short. Look at the examples in PEP 8: def __init__(self, width, height, color='black', emphasis=None, highlight=0): What about that code is "too verbose"? It's an extremely simple constructor with 6 arguments (5 explicit). I understand that readability is subjective, but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one.
- stormbrew 13y ago
  Exactly. 80 columns with python is incredibly frustrating to hold to. Python is a verbose language at the best of times, when you add in 4 or even 8 column indent it's just silly. 20% of your line is probably taken up by leading spaces or one or more 'self.'s. The introduction of keyword args only compounded the issue.
- acjohnson55 13y ago
  I think it's worth the time to spend a little while with an IDE that PEP-8 checks your code in real-time. It really forces you to think about better formatting and breaking up complex statements. In your example, if my declaration is running that long, I put the first line break after the open-parenthesis. Then all parameters end up in a nice block, and I've found that to be very easy on the eyes when going back to look at forgotten code. Generally speaking, I've found that adhering to the 80-char limit has greatly improved my code formatting and readability. 100 is okay with me too, though.
- Anderkent 13y ago
  >but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one. FWIW, I do. Especially since the new line is a clear point of separation between required and optional arguments. But I also find HN extremely hard to read because of the ridiculously long lines, and often find myself jumping to the wrong line when I reach end of the screen.
  - baddox 13y ago
    I hadn't noticed the line break serving as the separation between required and optional arguments. That's a good point, and I now don't see an issue with that particular line break in that context. But I still think it's silly to always break at 80 character in similar examples.

by d23 13y ago

baddox 13y ago

> 1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. I completely disagree, partly because I prefer to err on the side of verboseness, and partly because 80 is just ridiculously short. Look at the examples in PEP 8: def __init__(self, width, height, color='black', emphasis=None, highlight=0): What about that code is "too verbose"? It's an extremely simple constructor with 6 arguments (5 explicit). I understand that readability is subjective, but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one.

stormbrew 13y ago
Exactly. 80 columns with python is incredibly frustrating to hold to. Python is a verbose language at the best of times, when you add in 4 or even 8 column indent it's just silly. 20% of your line is probably taken up by leading spaces or one or more 'self.'s. The introduction of keyword args only compounded the issue.
acjohnson55 13y ago
I think it's worth the time to spend a little while with an IDE that PEP-8 checks your code in real-time. It really forces you to think about better formatting and breaking up complex statements. In your example, if my declaration is running that long, I put the first line break after the open-parenthesis. Then all parameters end up in a nice block, and I've found that to be very easy on the eyes when going back to look at forgotten code. Generally speaking, I've found that adhering to the 80-char limit has greatly improved my code formatting and readability. 100 is okay with me too, though.
Anderkent 13y ago
>but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one. FWIW, I do. Especially since the new line is a clear point of separation between required and optional arguments. But I also find HN extremely hard to read because of the ridiculously long lines, and often find myself jumping to the wrong line when I reach end of the screen.
- baddox 13y ago
  I hadn't noticed the line break serving as the separation between required and optional arguments. That's a good point, and I now don't see an issue with that particular line break in that context. But I still think it's silly to always break at 80 character in similar examples.