5 ms·

Ah, leave people alone. I stopped using ternary expressions because someone told me not to. I could start using them again, whatever. I use while loops when

Ah, leave people alone. I stopped using ternary expressions because someone told me not to. I could start using them again, whatever. I use while loops when the burden of describing the loop as an iteration is too high (too much of a stretch), or when I'm writing something that really isn't a composition of forEach/map/filter/reduce (gasp). For me, it's whatever I need to do to get through code review without arguing too much. Don't add linter checks for these things, it's condescending. At the very least, have the "greater good" on your side, e.g. "it confuses some people!" or "it is often a bug!" or "it can become a maintenance nightmare!" or whatever. If your reason is "I like it better this way," well then yeah, the reaction I would anticipate is "who asked you?" The reason this bothers me isn't that I strongly disagree, but that I'm in the habit of doing whatever my linter tells me, and adding stuff like this cheapens the thing and makes it harder to sell to "I'm an expert, get off my lawn" people. Why am I even writing this, I'm knee deep in C++ these days.

heresie-dabord 5y ago
> For me, it's whatever I need to do to get through code review without arguing too much. The language quibblers of the programming industry have installed a set of opinions, not knowledge. They proceed to waste time and energy with their assertions.
- musingsole 5y ago
  > The language quibblers of the programming industry have installed a set of opinions Pray they don't install another one.
tbronchain 5y ago
This, really. I'm most likely less experiment than some people here but after 10+ years of writing code, I came to the conclusion that the best code is the most readable code. If all developers could write code that is easily readable for them (even after a few months break in the project), the software engineering world would be a lot better :) Of course it makes sense to avoid anti-patterns and bottlenecks, but no much more really.
- samhh 5y ago
  Readability is largely subjective. I think this sentiment is better described as optimising readability for the lowest common denominator in terms of both ability/experience and the most common style of code, that being imperative. That's not an unreasonable choice to make but there are other criterion by which to judge how easy or hard code is to read. It comes up a lot in discussions about Go. A simple, "readable" language in which I can't tell you at a glance what a block of code does or is responsible for.
Chris2048 5y ago
> For me, it's whatever I need to do to get through code review without arguing too much. I agree with this. It takes a lot of context to truly understand another's code so reviews are just smoke & style checks, not real logic scrutiny like a kernel dev might do - in most cases businesses aren't willing to accept the true cost of such a review; I think the same is true of KT. > Don't add linter checks for these things, it's condescending. disagree. wrt pep-8 stuff, devs should be using their own linters before code is properly committed and for review. CI checks are easy to add and manage a quick/easy rebuke for the dev that doesn't bother. For other style lints, tools that standardise trivial things (style w/ black, orderings w/ isort) reduce arguments and establish a consistent style. Code in whatever style you like, just standardise it for consumption. devs then argue at a higher level instead: over linter parameters.
fogof 5y ago
> Don't add linter checks for these things, it's condescending. Well as he states, these checks are not turned on by default. I have trouble seeing why someone who liked these extensions enough to turn them on manually would feel condescended to by them.
- deleted 5y ago
  [deleted]
- MathMonkeyMan 5y ago
  Fair point, I'm being defensive unnecessarily. It still puts me off slightly that the tool mixes "make your code less prone to error" with "this guy wants this." Ok, live and let live. I'm reminded of Douglas Crockfords's jslint, which is a mix of "this caused bugs before" with "how I write javascript."
strken 5y ago
I think the biggest proof that linting in general is not condescending against any one style is the frequent existence of multiple mutually exclusive linter checks, one for each style. Consistent style is really nice.
- brundolf 5y ago
  I'm in the camp that "style" has very little real impact on readability, and linting for it mostly just creates friction. Maybe one time out of 100 I've got a weird case that truly needs to be indented differently, but my linter forbids it as dogma, so I either end up with code that's less readable or I add the noise of linter-disabling comments. The things that really impact how understandable some code is have little to do with punctuation, or whether or not these two characters have a space in-between, or what type of quotes we use.
danudey 5y ago
From the page: > Generally speaking, less code is better than more code This is true, but, generally speaking, readable code is better than compact code. Making it harder to scan through the code, or requiring more horizontal reading to understand code while you're scanning through it, is objectively bad. This is going to push people towards making less-readable code for literally zero benefit. Considering how many of the checks in pylint are to make your code more readable, this is a clear step backwards. I agree with him about the problems involved in while loops; there are cases where what you actually want is "loop forever until you die", but they are pretty rare, and all the rest can be converted into some other form of loop; that said, those situations also seem to more likely complicate the understanding of your code in many situations. All in all, while-used is highly opinionated but has a point to make; consider-ternary-expression is an asinine addition that's going to push people towards writing objectively worse code for literally no benefit other than reducing line count. If that's your KPI, then sure, fill your boots, but it makes zero sense to enable it by default. Edit: To clarify, it does not seem as though PyLint is enabling this by default, but I'm concerned that some shops will enable it by default and push their developers to write worse code.
- munch117 5y ago
  This is why I only ever run PyLint with the -E option, which makes it focus on diagnosing actual bugs. I am concerned about the trend in Python open-source projects to consider any deviation from their machine-checked coding style a bug. There's pylint and pep8 and isort and 'black' - the list grows ever longer. I kinda like it when people yell at me for submitting a patch without tests. Having quality standards is great. I like it a lot less when some CI machine yells at me for failing to put the "correct" number of blanks lines between methods.
omegalulw 5y ago
> For me, it's whatever I need to do to get through code review without arguing too much. This seems like a horrible attitude, if everyone did this codebase will go downhill really fast. Sometimes you have to use better/new practices and successfully advocate for them in code review. > Don't add linter checks for these things, it's condescending. Automated standardized checks are "condescending"? > but that I'm in the habit of doing whatever my linter tells me Sounds like you need to improve your lint checks. You _should_ usually be accepting the vast majority of lint auto fixes.

heresie-dabord 5y ago

> For me, it's whatever I need to do to get through code review without arguing too much. The language quibblers of the programming industry have installed a set of opinions, not knowledge. They proceed to waste time and energy with their assertions.

musingsole 5y ago
> The language quibblers of the programming industry have installed a set of opinions Pray they don't install another one.

tbronchain 5y ago

This, really. I'm most likely less experiment than some people here but after 10+ years of writing code, I came to the conclusion that the best code is the most readable code. If all developers could write code that is easily readable for them (even after a few months break in the project), the software engineering world would be a lot better :) Of course it makes sense to avoid anti-patterns and bottlenecks, but no much more really.

samhh 5y ago
Readability is largely subjective. I think this sentiment is better described as optimising readability for the lowest common denominator in terms of both ability/experience and the most common style of code, that being imperative. That's not an unreasonable choice to make but there are other criterion by which to judge how easy or hard code is to read. It comes up a lot in discussions about Go. A simple, "readable" language in which I can't tell you at a glance what a block of code does or is responsible for.

Chris2048 5y ago

> For me, it's whatever I need to do to get through code review without arguing too much. I agree with this. It takes a lot of context to truly understand another's code so reviews are just smoke & style checks, not real logic scrutiny like a kernel dev might do - in most cases businesses aren't willing to accept the true cost of such a review; I think the same is true of KT. > Don't add linter checks for these things, it's condescending. disagree. wrt pep-8 stuff, devs should be using their own linters before code is properly committed and for review. CI checks are easy to add and manage a quick/easy rebuke for the dev that doesn't bother. For other style lints, tools that standardise trivial things (style w/ black, orderings w/ isort) reduce arguments and establish a consistent style. Code in whatever style you like, just standardise it for consumption. devs then argue at a higher level instead: over linter parameters.

fogof 5y ago

> Don't add linter checks for these things, it's condescending. Well as he states, these checks are not turned on by default. I have trouble seeing why someone who liked these extensions enough to turn them on manually would feel condescended to by them.

deleted 5y ago
[deleted]
MathMonkeyMan 5y ago
Fair point, I'm being defensive unnecessarily. It still puts me off slightly that the tool mixes "make your code less prone to error" with "this guy wants this." Ok, live and let live. I'm reminded of Douglas Crockfords's jslint, which is a mix of "this caused bugs before" with "how I write javascript."

strken 5y ago

I think the biggest proof that linting in general is not condescending against any one style is the frequent existence of multiple mutually exclusive linter checks, one for each style. Consistent style is really nice.

brundolf 5y ago
I'm in the camp that "style" has very little real impact on readability, and linting for it mostly just creates friction. Maybe one time out of 100 I've got a weird case that truly needs to be indented differently, but my linter forbids it as dogma, so I either end up with code that's less readable or I add the noise of linter-disabling comments. The things that really impact how understandable some code is have little to do with punctuation, or whether or not these two characters have a space in-between, or what type of quotes we use.

danudey 5y ago

From the page: > Generally speaking, less code is better than more code This is true, but, generally speaking, readable code is better than compact code. Making it harder to scan through the code, or requiring more horizontal reading to understand code while you're scanning through it, is objectively bad. This is going to push people towards making less-readable code for literally zero benefit. Considering how many of the checks in pylint are to make your code more readable, this is a clear step backwards. I agree with him about the problems involved in while loops; there are cases where what you actually want is "loop forever until you die", but they are pretty rare, and all the rest can be converted into some other form of loop; that said, those situations also seem to more likely complicate the understanding of your code in many situations. All in all, while-used is highly opinionated but has a point to make; consider-ternary-expression is an asinine addition that's going to push people towards writing objectively worse code for literally no benefit other than reducing line count. If that's your KPI, then sure, fill your boots, but it makes zero sense to enable it by default. Edit: To clarify, it does not seem as though PyLint is enabling this by default, but I'm concerned that some shops will enable it by default and push their developers to write worse code.

munch117 5y ago
This is why I only ever run PyLint with the -E option, which makes it focus on diagnosing actual bugs. I am concerned about the trend in Python open-source projects to consider any deviation from their machine-checked coding style a bug. There's pylint and pep8 and isort and 'black' - the list grows ever longer. I kinda like it when people yell at me for submitting a patch without tests. Having quality standards is great. I like it a lot less when some CI machine yells at me for failing to put the "correct" number of blanks lines between methods.

omegalulw 5y ago

> For me, it's whatever I need to do to get through code review without arguing too much. This seems like a horrible attitude, if everyone did this codebase will go downhill really fast. Sometimes you have to use better/new practices and successfully advocate for them in code review. > Don't add linter checks for these things, it's condescending. Automated standardized checks are "condescending"? > but that I'm in the habit of doing whatever my linter tells me Sounds like you need to improve your lint checks. You _should_ usually be accepting the vast majority of lint auto fixes.