Your code style guide is crap, but still better than nothing.
tech.matchfwd.com
Your code style guide is crap, but still better than nothing.
1–10 of 49 posts
Re: Your code style guide is crap, but still better than nothing.
#2Fun fact: the VT-100 supported a 132-column display.
Anyway, there's a lot of advantages of trying to keep lines <= 78 columns wide. I don't make it a hard-and-fast rule, but usually overly long line is a sign that something's not right with the code and some refactoring is in order.
Re: Your code style guide is crap, but still better than nothing.
#380 character line length increases readability, and four spaces means that this is consistent everywhere.
If you have a tab character and someone sets things to like, two spaces, their line is going to be a dynamic length and it's going to shit up the code. PEP-8 looks fantastic, works, and leads to consistency across all Python code. Unless you are using a shitty IDE/editor, adhering to it is totally easy and completely painless.
Re: Your code style guide is crap, but still better than nothing.
#4I closed the tab at the "Line Length" header; yet another person who Doesn't Get It, and proudly refuses to. There's a reason besides technical limitations (which in reality, didn't exist) that columns are best set to be no longer than 80 characters. Just as a hint, would you like to dump all your code into a single function in one file? No? Didn't think so.
Edit: I lied, I kept reading. Oh, why did I do that. Tabs instead of spaces because it looks better on his iOS devices? This article is bad, and the author should feel bad.
Re: Your code style guide is crap, but still better than nothing.
#580 character line length increases readability, and four spaces means that this is consistent everywhere. If you have a tab character and someone sets things to like, two spaces, their line is going to be a dynamic length and it's going to shit up the code. PEP-8 looks fantastic, works, and leads to consistency across all Python code. Unless you are using a shitty IDE/editor, adhering to it is totally easy and comple…
I do not understand why there seem to be so much agreement on 80 characters line length. I often use 132 character. I have a rule that invite to avoid abbreviations in identifiers and I have often 4 spaces. If I limit to 80 character, all the line breaks decrease significantly readability.
Re: Your code style guide is crap, but still better than nothing.
#680 character line length increases readability, and four spaces means that this is consistent everywhere. If you have a tab character and someone sets things to like, two spaces, their line is going to be a dynamic length and it's going to shit up the code. PEP-8 looks fantastic, works, and leads to consistency across all Python code. Unless you are using a shitty IDE/editor, adhering to it is totally easy and comple…
I do not understand why there seem to be so much agreement on 80 characters line length. I often use 132 character. I have a rule that invite to avoid abbreviations in identifiers and I have often 4 spaces. If I limit to 80 character, all the line breaks decrease significantly readability.
Code is just like literature. Too many words on a line and it looses the reader. All of this indeed depends on the density of the language you're using. If your're using extremelyLongVariableNames it may be ok to use 132 characters per lines but if you use shorter var_names, 80 characters is plenty of room to express yourself^W^Wwrite code.
Also, unix. Stop arguing about religion.
Re: Your code style guide is crap, but still better than nothing.
#7Fun fact: the VT-100 supported a 132-column display. Anyway, there's a lot of advantages of trying to keep lines <= 78 columns wide. I don't make it a hard-and-fast rule, but usually overly long line is a sign that something's not right with the code and some refactoring is in order.
Why is a ~130-column line of code necessary a bad thing? I'm not saying it's good and that we should shoot for any specific number, but I don't see why shorter necessarily means better.
Disclaimer: I've been doing this for all of ~5 years so I have no experience with older terminal-style programming.
Re: Your code style guide is crap, but still better than nothing.
#8I closed the tab at the "Line Length" header; yet another person who Doesn't Get It, and proudly refuses to. There's a reason besides technical limitations (which in reality, didn't exist) that columns are best set to be no longer than 80 characters. Just as a hint, would you like to dump all your code into a single function in one file? No? Didn't think so. Edit: I lied, I kept reading. Oh, why did I do that. Tabs i…
Maybe I`m biased because I write C on a daily basis, and only noodle around with Python occasionally:
- Having a standard line length is awesome. I can fit 3 80x4 terminals on my 1920x1080 screen, and I never have worry about anything overflowing or wrapping. You could pick a different length, if you`d like, but 80 is convenient.
- I`ve seen the `you can set tabs to whatever you want` argument before. It`s obviously at odds with the 80-column rule, because if you open it with the wrong config, wrapping everywhere. This happens disproportionately to new users - new hires and interns - and it`s a big pain to explain every time. Then they turn around and hit space 4 times anyways.
Your code style rules should definitely match your language. The author seems to be complaining that C-style rules don`t apply to Python. You`d think he would`ve realized when they started talking about wrapping if blocks in {}
Re: Your code style guide is crap, but still better than nothing.
#9Fun fact: the VT-100 supported a 132-column display. Anyway, there's a lot of advantages of trying to keep lines <= 78 columns wide. I don't make it a hard-and-fast rule, but usually overly long line is a sign that something's not right with the code and some refactoring is in order.
Why is a ~130-column line of code necessary a bad thing? I'm not saying it's good and that we should shoot for any specific number, but I don't see why shorter necessarily means better. Disclaimer: I've been doing this for all of ~5 years so I have no experience with older terminal-style programming.
Well, I'd say it's highly language dependent, and a matter of sane preceding white space rules. Going by column count, ObjC or Java would be a million miles away from, say, C or Haskell.
I would argue that that's a mark against the former, but if you're using languages like them it's silly to try and fit everything into 80 characters. You still need a strict rule, btw: sooner or later some jackass will be putting in 200+ if you're not careful, which is insane in any language because it's utterly unreadable.
It has to do with how the eye physically moves: you want a given block of logic to be as square as possible, so moving from one portion of it to another, on average, minimizes the amount of distance your eye has to travel.
Re: Your code style guide is crap, but still better than nothing.
#10Fun fact: the VT-100 supported a 132-column display. Anyway, there's a lot of advantages of trying to keep lines <= 78 columns wide. I don't make it a hard-and-fast rule, but usually overly long line is a sign that something's not right with the code and some refactoring is in order.
Why is a ~130-column line of code necessary a bad thing? I'm not saying it's good and that we should shoot for any specific number, but I don't see why shorter necessarily means better. Disclaimer: I've been doing this for all of ~5 years so I have no experience with older terminal-style programming.
I generally disapprove of >80 width lines, but there are some cases in which they don't bother me, and that is boilerplate-ish code that you generally don't have to read all of to understand what it's for. For example macro-heavy C++ header definitions where each line ends in the same massive pile of definition.
The important bit for me seems to be that the stuff you have to read and understand should be in the <80 area.