34 ms·

Do you find your team enforcing the string quote rule consistently? It seems to me like it's easy to miss at times as automatic enforcement is impossible. Are

Do you find your team enforcing the string quote rule consistently? It seems to me like it's easy to miss at times as automatic enforcement is impossible. Are there no cases where a string that wasn't originally planned to be user-visible ends up being so? I've heard this idea at times but when I looked at actual codebases it turns out it's more of an aspiration than an actual rule. And if you can't depend on it, why have it? As for number of lines after imports, how is a lack of enforcement there stopping you from using the tool? Black enforces one line but is fine if you put two (on module level). In general, if you give up on the tool due to a missing rule, you end up having to manually enforce tens of other rules that you'd otherwise be free from.

lambda 8y ago
I kind of subconsciously do the same thing; use single quotes for symbol-like strings, and double for human readable. But I can buy the argument that just having a single auto-enforced rule improves consistency and that has greater benefits than the somewhat vague distinction that is not enforced.
yycom 8y ago
> And if you can't depend on it, why have it? That's a bit rich. There are other conventions in programming that you can't depend on technically but serve a real purpose. Identifier naming and comments are the first that come to mind. If a language gives you a choice of token that has no semantic distinction then different people will adopt different semantics by convention. As an aside, calling a tool "opinionated" is code for "my conventions are better than yours". That's fine if I don't have any conventions or I can't decide, but if I have decided, then it's just offensive.
- zestyping 8y ago
  Sometimes it's helpful just to have a decision; any decision, followed consistently, is better than no decision or continued debate. This is one of those situations. So I don't read "opinionated" to necessarily mean "better than your opinions"; it's more like "makes decisions for you so you can avoid the cost of debating them."
  - yycom 8y ago
    And what if I have already incurred the cost and am happy with my decisions, and they differ to yours? I now cannot use your potentially useful tool, even if 90% of our decisions do accord with each other. That's disappointing.
- jrs95 8y ago
  Comments are often a side of poorly written code though. Ideallly the name and structure of the program should make the intent and purpose obvious, which eliminates the need for a lot of the comments people leave. Of course this isn’t always true, but if you’re using comments to compensate for bad/confusing code, you shouldn’t think you’re doing “the right thing”.
danpalmer 8y ago
> Do you find your team enforcing the string quote rule consistently? Yes. It's pretty much the only formatting style point that we don't have automated. > As for number of lines after imports, how is a lack of enforcement there stopping you from using the tool? Our current automated linting enforces it, but Black doesn't always reformat it, so we might get linter errors from Black formatted code.
- ambivalence 8y ago
  > Yes. It's pretty much the only formatting style point that we don't have automated. Alright, fair enough! > Black doesn't always reformat it, so we might get linter errors from Black formatted code. Well, as long as it doesn't add new linter errors, that should be fine, do you disagree? There are always going to be suboptimal formattings and missing transformations but as long as the situation gets better automatically on average and can be further improved with minimal manual input, you should be fine.

lambda 8y ago

I kind of subconsciously do the same thing; use single quotes for symbol-like strings, and double for human readable. But I can buy the argument that just having a single auto-enforced rule improves consistency and that has greater benefits than the somewhat vague distinction that is not enforced.

yycom 8y ago

> And if you can't depend on it, why have it? That's a bit rich. There are other conventions in programming that you can't depend on technically but serve a real purpose. Identifier naming and comments are the first that come to mind. If a language gives you a choice of token that has no semantic distinction then different people will adopt different semantics by convention. As an aside, calling a tool "opinionated" is code for "my conventions are better than yours". That's fine if I don't have any conventions or I can't decide, but if I have decided, then it's just offensive.

zestyping 8y ago
Sometimes it's helpful just to have a decision; any decision, followed consistently, is better than no decision or continued debate. This is one of those situations. So I don't read "opinionated" to necessarily mean "better than your opinions"; it's more like "makes decisions for you so you can avoid the cost of debating them."
- yycom 8y ago
  And what if I have already incurred the cost and am happy with my decisions, and they differ to yours? I now cannot use your potentially useful tool, even if 90% of our decisions do accord with each other. That's disappointing.
jrs95 8y ago
Comments are often a side of poorly written code though. Ideallly the name and structure of the program should make the intent and purpose obvious, which eliminates the need for a lot of the comments people leave. Of course this isn’t always true, but if you’re using comments to compensate for bad/confusing code, you shouldn’t think you’re doing “the right thing”.

danpalmer 8y ago

> Do you find your team enforcing the string quote rule consistently? Yes. It's pretty much the only formatting style point that we don't have automated. > As for number of lines after imports, how is a lack of enforcement there stopping you from using the tool? Our current automated linting enforces it, but Black doesn't always reformat it, so we might get linter errors from Black formatted code.

ambivalence 8y ago
> Yes. It's pretty much the only formatting style point that we don't have automated. Alright, fair enough! > Black doesn't always reformat it, so we might get linter errors from Black formatted code. Well, as long as it doesn't add new linter errors, that should be fine, do you disagree? There are always going to be suboptimal formattings and missing transformations but as long as the situation gets better automatically on average and can be further improved with minimal manual input, you should be fine.