7 ms·
If I could amend PEP 8
- Sivart13 10y agoIn situations where the language allows either quote, I think any ounce of time spent by anyone debating to use one or the other is pure waste, including this comment. Just do whatever you feel like. If your editor, linter, or review process makes you change it, those things are broken.
- akvadrako 10y agoInconsistency is not the end of the world but it hurts readability, slightly complicates find/replace and I find it just ugly. The fact that the codes works is most important, but being nice to work on comes a close second.
- antris 10y agoCode that doesn't work but is readable can at least be fixed.
- Daishiman 10y agoWith regards to string quotes, I've always used this idiom, which I find fantastic: For strings that are meant for human consumption, use double quotes, otherwise use single quotes. This is super practical when looking strings meant for translation, end-user formatting, and such.
- thebspatrol 10y agoI love this. I've always followed this guideline without thinking about how to communicate it. I'm fairly sure that single quotes are much more common in the UK in literature, though, so this only feels like it makes sense to NA and AU speakers.
- OJFord 10y ago> I'm fairly sure that single quotes are much more common in the UK in literature, though It's just that the primary/secondary role is reversed. (This is also reflected in which one you have to hold Shift for on a computer keyboard.)
- js8 10y agoFunny, I came here to suggest the same thing. It's a good rule.
- akvadrako 10y agoIt's not a good rule because nobody else uses it, so it's just going to make the code inconsistent when someone else works on it.
- js8 10y agoAll good rules started by nobody else using it. Though, in this case, at least three people discovered that rule independently.
- viraptor 10y agoAnd +1. I thought it's just me. It works quite well in practice and can be applied to many languages. Unfortunately in quite a few of them out prevents interpolation, so it's not a 100% solution.
- masklinn 10y ago> Unfortunately in quite a few of them out prevents interpolation, so it's not a 100% solution. A bigger issue IME is languages (mostly of the C family) where single-quoting is for character literals. Also in Smalltalk comments are double-quoted, but that's a pretty rare language to encounter.
- jsmeaton 10y agoI do. People I work with do. People I mentor do.
- Grue3 10y agoA lot of people use it. That's how I was taught to write Python and that's how I wrote it in several different companies. At my current job we use double-quotes for everything though (for some reason).
- masklinn 10y agoI like that Erlang more or less enforces that rule: strings are double-quoted, symbols are single-quoted, you generally use symbols for "programmatic strings".
- thesmallestcat 10y ago[$i, $n, $d, $e, $e, $d].
- Spiritus 10y ago>Line-length can exceed 79 characters, to 100, when convenient. My issue with this is that, in reality, everything will now be 100 chars.
- rootlocus 10y agoThere are actually few places where lines need to be this long. If you keep indentation low (by refactoring) most of the lines don't get to 80.
- zepolen 10y agoI don't agree with allowing characters to go over 80 - there is rarely a time the code can't be broken down to fit. 80 characters helps a lot since you can count on all code to fit within a certain area - so you can run three side/side text buffers in your text editor, instead of two with lots of useless white space because a few lines might be too long. Doing a simple overview of the requests library, most of the lines over 80 characters are just laziness such as: https://github.com/kennethreitz/requests/blob/master/tests/test_utils.py#L153 https://github.com/kennethreitz/requests/blob/master/tests/t... And a few of the actual potential cases for going over 80 characters can still be broken down without losing any readability: https://github.com/kennethreitz/requests/blob/master/requests/auth.py#L105 https://github.com/kennethreitz/requests/blob/master/request... r.headers['Proxy-Authorization'] = _basic_auth_str(self.username, self.password)
- ergo14 10y agoI have lots of classes and method names that are descriptive but also make 80 chars harder to read. In past I've had to sacrifice readibility to follow strict 80 char limit rule it is a bad idea to enforce it. 99% of time you are not doing merges that require you to have 3 side by side buffers. It makes no sense to point this as the main reason to maintain the limit in my opinion. 100 char limit is way more sane, 95% of time 79 is enough for me but for the remaining 5% to enforce it means to actually make it less readable or make more cryptic variable names which is even worse imo..
- zepolen 10y agoI like descriptive names too, EvenToThePointOfAbsurdity, but if the 80 char limit is starting to be imposing, it's usually an indication that code should be refactored as it's being indented too much, or one thing is trying to do too many things. 3 side/side buffers is arbitrary, (it would be 2 on a small laptop display) - and maybe that's why I like 80 characters, it lets me develop on any screen without needing more real estate because the files are long. I mean Angular has iirc 120 characters, and if you take a look at an average source file eg: https://github.com/angular/angular/blob/master/modules/%40angular/http/src/headers.ts https://github.com/angular/angular/blob/master/modules/%40an... You'll see a ton of white space after 80 characters that is 'wasted' - this also eats up into horizontal real estate of another buffer which in the end means you actually have less information on the screen with >80 characters rather than more. In all cases - the code in that file could easily be broken into multiple lines and not lose any readability.
- cdelsolar 10y agoHow do they suggest you indent function arguments? The Javascript way? Because I don't like that one at all.
- pmiller2 10y agoI think this concern over an absolute limit on line length is overblown. Where I work now, we don't use a hard limit on line length. The rule is "keep it readable." That usually means lines less than 100 characters. I try to keep it below 80 myself, but I wouldn't complain about a 120 character line. I did a search through our codebase for line lengths over 80 or 100 characters and found remarkably few. Most were comment lines.
- guitarbill 10y agoAgreed, "aligned with opening delimiter" is brain dead, you just waste time re-justify everything if you refactor. It's just more effort in the long run, and for what? It isn't prettier, more readable, or more convenient. As for strings, meh. But consistency is nice. Line length exceeding an arbitrary standard, fine. Rules can be broken if there's a good reason.
- merlincorey 10y ago> Agreed, "aligned with opening delimiter" is brain dead, As a smug lisp weenie that has been working in python for many years, I completely disagree with this. > you just waste time re-justify everything if you refactor. A single `indent-region` in emacs and you are rejustified, no trouble. > It's just more effort in the long run, and for what? It's more effort as opposed to what, exactly? > It isn't prettier, more readable, or more convenient. It is, to me, prettier, but I think, objectively, it is more readable than alternatives, especially if there is any kind of nesting involved. I concede that if there is nesting involved, you might be bumping into other python style issues, and generally might want to add some intermediate variables, etc; however, I do believe that in at least some cases this is entirely inconvenient, and so the lisp way of aligning parameters with their delimiter is the way to go in those cases. Anything else would be quite a bit less readable.
- antris 10y ago> A single `indent-region` in emacs and you are rejustified, no trouble. Yeah, I'll just change my text editor because someone in the team wants to use this rule. So convenient.
- odiroot 10y agoPersonally, I would have hard time with single quotes point. Double quotes are just so much easier to catch visually.
- akvadrako 10y agoNot with color syntax highlighting. I find double quotes unnecessary noise.
- Smaug123 10y agoThe one I don't like is the asymmetrical block-quotes in docstrings: """This line doesn't start at the start. But this one does, and the following one ends at the start. """
- EvilTerran 10y agoYeah, agreed. My multiline strings (docstring or otherwise) almost always look like """\ This line starts at the start. And so do the following ones. """
- Acalyptol 10y agoFor me having to read even the ugliest code is better than having to horizontally scroll. Anyone who thinks there is a single one line of code for which it's legit to go beyond 80 characters is either masochist or using a view with more than 80 characters in available width.
- pmontra 10y agoI use a proportional font so it's hard to know where the 80th character is. I just try to be reasonable. Btw, proportional fonts look much better. It took a week to adapt. What I'll amend is the rule about not having spaces around = in argument lists. It looks horrible and it induces some people at omitting spaces in assignments. I've never seen so many var=value in source code as in Python, since the time of PHP.