7 ms·

I really want to use Black, but we have a particular style point that we’d miss so much that we haven’t adopted it yet... Double quotes for strings that need t

I really want to use Black, but we have a particular style point that we’d miss so much that we haven’t adopted it yet... Double quotes for strings that need to be human readable, single quotes otherwise. This makes it so obvious when something is going to be sent to the user, we find it really useful. That said, I think Black’s appeal is it’s uncompromising nature, so I wouldn’t ask it to change. Adding the option to turn off quote formatting would probably go against its vision. Also, it could be argued that we should use the internationalisation functions to denote strings sent to the user, but hey we don’t do i18n yet. For now, this, and one or two places that it fails to have an opinion (number of lines after imports) are keeping us from using it.

ambivalence 8y ago
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.
bpicolo 8y ago
Could fork it and remove that rule
waleedka 8y ago
One idea you might want to consider is to create a global function, let’s call it h() and pass all your human readable strings through it, like so h(“hello world”). This function, simply returns the same string. This is more explicit than relying on quote types. It also allows you to do interesting things such as logging everything to a text file and running a spell checker on it, or checking for wrongly encoded string, ...etc.
- demosito666 8y ago
  I believe _() would be even better, granted you might want to translate messages in future. At first might just def _(s): return s.
  - ComputerGuru 8y ago
    A single underscore is pretty much de facto reserved for localization.
    - jedberg 8y ago
      Which is exactly what this is. Putting everything a human reads into a function is step one of localization.
- danpalmer 8y ago
  Yep, as others have commented, this is what I meant by using the translation tools.
- cup-of-tea 8y ago
  That's pretty standard in libraries that do i18n (like Qt, for example). It's a very good practice IMO. Not only does it enable i18n, it means you can easily collect every user-destined string and check it for things like forbidden words etc.
nicpottier 8y ago
We did this as well, but I think the benefits of black and auto-formatting outweigh losing this convention.
Too 8y ago
Why would you have strings that are not supposed to be human readable? Machine to machine should ideally use bytearray (b""-strings) or integer enums for that purpose. Then you also have the ambiguity of what is considered human readable, is an xml document human readable? Http headers? File paths? Urls? Is a programmer considered human?
- zachsnow 8y ago
  I believe the point is whether the string is intended to be displayed to a human, not whether a human might read it in the code. Still some wiggle room around logging, etc. I guess.
  - Too 8y ago
    Sorry if i wasn't clear, what i meant was actually why would you have strings that are not intended to be displayed to end user? Smells like non binary serialization format or something alike, which is usually a code smell. It's convenient the first 2 weeks but once the project grows you need a more strict schema and once you have that you might as well use a serialization library which might as well have a binary serialization backend.
    - aldanor 8y ago
      > why would you have strings that are not intended to be displayed to end user Why would you not? E.g., you use pandas and columns all have names. Colors are typically also strings, etc. Thus you would often do things like grouped = df.groupby(['foo', 'bar'])['baz'].mean() However, the parent's point, IIUC, is that he'd do grouped.plot(color='red', title="User-facing title.")
      - Too 8y ago
        Colors as strings is a perfect example of what i'm trying to question here. How do i know which colors that are valid? Run time error? No thanks. Reading online documentation[0]? No thanks. I'd rather have my auto-complete[0] tell me right away the available options and my compiler tell me if i misspelled 'turquoiuse'. A better solution for this is a color-class with a long list of predefined colors as constants, and since they are just constants they could have any underlying format, not necessarily a string. Even in a dynamic language such as python this should be preferred over random strings. Then yes, there are valid uses, especially in ad-hoc scripts. Column names and dictionary keys are one of the gray zones, though again, in my experience once your project grows these are also usually better to code generate from your db schema or serialization protocol; either complete data structures, api-functions, or just a list of constants. Anyway, my point is not to ban strings entirely, it's to question what we use it for. If you use strings as data/identifiers so frequently that you need a special convention for them something smells quite fishy. [0] Auto complete = More accessible form of documentation. Before someone starts screaming that i'm stupid for "ignoring documentation".

ambivalence 8y ago

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.

bpicolo 8y ago

Could fork it and remove that rule

waleedka 8y ago

One idea you might want to consider is to create a global function, let’s call it h() and pass all your human readable strings through it, like so h(“hello world”). This function, simply returns the same string. This is more explicit than relying on quote types. It also allows you to do interesting things such as logging everything to a text file and running a spell checker on it, or checking for wrongly encoded string, ...etc.

demosito666 8y ago
I believe _() would be even better, granted you might want to translate messages in future. At first might just def _(s): return s.
- ComputerGuru 8y ago
  A single underscore is pretty much de facto reserved for localization.
  - jedberg 8y ago
    Which is exactly what this is. Putting everything a human reads into a function is step one of localization.
danpalmer 8y ago
Yep, as others have commented, this is what I meant by using the translation tools.
cup-of-tea 8y ago
That's pretty standard in libraries that do i18n (like Qt, for example). It's a very good practice IMO. Not only does it enable i18n, it means you can easily collect every user-destined string and check it for things like forbidden words etc.

nicpottier 8y ago

We did this as well, but I think the benefits of black and auto-formatting outweigh losing this convention.

Too 8y ago

Why would you have strings that are not supposed to be human readable? Machine to machine should ideally use bytearray (b""-strings) or integer enums for that purpose. Then you also have the ambiguity of what is considered human readable, is an xml document human readable? Http headers? File paths? Urls? Is a programmer considered human?

zachsnow 8y ago
I believe the point is whether the string is intended to be displayed to a human, not whether a human might read it in the code. Still some wiggle room around logging, etc. I guess.
- Too 8y ago
  Sorry if i wasn't clear, what i meant was actually why would you have strings that are not intended to be displayed to end user? Smells like non binary serialization format or something alike, which is usually a code smell. It's convenient the first 2 weeks but once the project grows you need a more strict schema and once you have that you might as well use a serialization library which might as well have a binary serialization backend.
  - aldanor 8y ago
    > why would you have strings that are not intended to be displayed to end user Why would you not? E.g., you use pandas and columns all have names. Colors are typically also strings, etc. Thus you would often do things like grouped = df.groupby(['foo', 'bar'])['baz'].mean() However, the parent's point, IIUC, is that he'd do grouped.plot(color='red', title="User-facing title.")
    - Too 8y ago
      Colors as strings is a perfect example of what i'm trying to question here. How do i know which colors that are valid? Run time error? No thanks. Reading online documentation[0]? No thanks. I'd rather have my auto-complete[0] tell me right away the available options and my compiler tell me if i misspelled 'turquoiuse'. A better solution for this is a color-class with a long list of predefined colors as constants, and since they are just constants they could have any underlying format, not necessarily a string. Even in a dynamic language such as python this should be preferred over random strings. Then yes, there are valid uses, especially in ad-hoc scripts. Column names and dictionary keys are one of the gray zones, though again, in my experience once your project grows these are also usually better to code generate from your db schema or serialization protocol; either complete data structures, api-functions, or just a list of constants. Anyway, my point is not to ban strings entirely, it's to question what we use it for. If you use strings as data/identifiers so frequently that you need a special convention for them something smells quite fishy. [0] Auto complete = More accessible form of documentation. Before someone starts screaming that i'm stupid for "ignoring documentation".