7 ms·

I've been using it for a few months now, but I don't really like it. It does remove quabbles about formatting, but I've personally never felt that as a problem

by CrLf 7y ago

I've been using it for a few months now, but I don't really like it. It does remove quabbles about formatting, but I've personally never felt that as a problem and it just replaces them with constant frustration. I think code formatting is very important for readability, and I think many (subtle) choices about how to make a piece of code more readable are very subjective. These types of tools are just incapable to make those choices because they have no concept of intention. And some rules make this painfully obvious even in less subjective cases. Eg: black formats dictionaries into a single line if they fit one line, which makes nested structures unreadable if they combine bigger and smaller sub-dictionaries. In the end, I don't have problems with other peoples' formatting choices; as long as they are sufficiently consistent within their own style, which they usually are, I can live just fine with them even when they go against how I'd do things. I do have problems with tools that reduce code readability for consistency's sake and argue that these provide little benefit, and may even be detrimental to code quality.

skybrian 7y ago
Are you sending unfortunate examples upstream? It's still beta, so it can be improved somewhat.
- CrLf 7y ago
  No, because I believe this is fundamentally unfixable. It's not a matter of changing this or that behavior, it's a matter of (apparent) formatting inconsistencies being important to convey intention and distinguish more important from less important bits. In the example I mentioned, I may sometimes choose to put a small dictionary initialization into a single line if it's just a detail, or may split it into multiple lines if it's important enough for someone reading the code to pay attention to it before going further. This simply cannot be decided by an automatic formatter without it knowing the code's purpose which, for now, requires a human brain. Someone mentioned elsewhere that automatic formatters remove the cognitive load of formatting code, but I argue that load is an intrinsic part of programming, because it is (for the most part) the effort of communicating to the next person that comes along.
  - zild3d 7y ago
    why not use their ```# fmt: off``` ? I have not used Black, but considering it so I am curious about these occasional situations where you want to override auto-formatting
    - arnioxux 7y ago
      I write a lot of scientific code with python and in those cases you really want your equations and matrix columns aligned for readability. These matrices appear so often adding fmt:off destroys the readability/elegance gain from the clever formatting. Here's an example snippet by Peter Norvig that is beautifully formatted: def neighbors4(point): "The four neighboring squares." x, y = point return ( (x, y-1), (x-1, y), (x+1, y), (x, y+1)) def neighbors8(point): "The eight neighboring squares." x, y = point return ((x-1, y-1), (x, y-1), (x+1, y-1), (x-1, y), (x+1, y), (x-1, y+1), (x, y+1), (x+1, y+1))
  - skybrian 7y ago
    Well sure, but an automatic formatter can still be better or worse. Maybe it won't be as good as hand-crafted formatting, but more bad examples can be avoided.
  - lysium 7y ago
    There is #format off for these few cases.
  - hrktb 7y ago
    I don’t code in python so have no opinion on Black, but most code formatter can be adjusted to exclude some cases of formatting. I you would be fine with 95% of what it does and just want it to ignore the 5% where you care the most, I think the tool could benefit you. At least that’s how I feel about autoformatting in general.
    - akvadrako 7y ago
      Black is specifically designed to avoid being customizable, so you can't just exclude some cases.
photonios 7y ago
You could configure your IDE to re-format files into your favorite format and just have a pre-commit hook that formats them back into the official format. That's how I work. No arguments about style and formatting, yet I get to make the code look how I personally prefer it.
- CrLf 7y ago
  There is no such thing as "my favorite format" in that sense. Also, I don't mind reading code in other people's "favorite format" nor do I have any problem in following another person's style if that's the style agreed upon by the team.
- a1369209993 7y ago
  No, we can't. My (and, by the sound of it, CrLf's) favorite format relies on information that your pre-commit hook has artificially removed from the code. Eg: munge(gidget, thing1,thing2,thing3); cmplt(dtypeA,valueA, dtypeB,valueB); (Most cases are more subtle (and thus less amenable to "oh, you just need to build a complete static type checker into the formatter") than this, but I wanted an obvious example.)
  - RussianCow 7y ago
    It seems like the signature of the functions should be different, especially the second example. I would have written the cmplt function to take tuple pairs: cmplt( (type_a, value_a), (type_b, value_b), ) That's much more clear about the relationship between each pair of values either way, and would get formatted nicely by Black.
    - a1369209993 7y ago
      Sorry, should have clarified: my example was written in C[0][1]; cmplt is something like (Dtyp* ,Dval* ,Dtyp* ,Dval* ), which is what I was alluding to with "just need a type checker". Also, in the code I anonymised that from, cmplt and munge are imported (well, #included) functions from a different library. 0: which doesn't have tuples anyway; you could use structs, but it doesn't really work well in context/practice. 1: I don't use python frecently enough to have ready examples of autoformatter stupidity on hand for it.
frosted-flakes 7y ago
> And some rules make this painfully obvious even in less subjective cases. Eg: black formats dictionaries into a single line if they fit one line, which makes nested structures unreadable if they combine bigger and smaller sub-dictionaries. Prettier for JS has a simple solution to this specific problem, and that is to follow the code's lead. If the first element of the object or array starts on the same line as the opening bracket, keep it as a single line if it fits. Otherwise, if the first element starts on a new line, put every element on a new line (explode the collection), even if they would all fit on a single line. Black should consider doing this instead of the open PR to explode collections if there is a trailing comma[0], which feels... wrong. [0] https://github.com/python/black/pull/826 https://github.com/python/black/pull/826

by CrLf 7y ago

skybrian 7y ago

Are you sending unfortunate examples upstream? It's still beta, so it can be improved somewhat.

CrLf 7y ago
No, because I believe this is fundamentally unfixable. It's not a matter of changing this or that behavior, it's a matter of (apparent) formatting inconsistencies being important to convey intention and distinguish more important from less important bits. In the example I mentioned, I may sometimes choose to put a small dictionary initialization into a single line if it's just a detail, or may split it into multiple lines if it's important enough for someone reading the code to pay attention to it before going further. This simply cannot be decided by an automatic formatter without it knowing the code's purpose which, for now, requires a human brain. Someone mentioned elsewhere that automatic formatters remove the cognitive load of formatting code, but I argue that load is an intrinsic part of programming, because it is (for the most part) the effort of communicating to the next person that comes along.
- zild3d 7y ago
  why not use their ```# fmt: off``` ? I have not used Black, but considering it so I am curious about these occasional situations where you want to override auto-formatting
  - arnioxux 7y ago
    I write a lot of scientific code with python and in those cases you really want your equations and matrix columns aligned for readability. These matrices appear so often adding fmt:off destroys the readability/elegance gain from the clever formatting. Here's an example snippet by Peter Norvig that is beautifully formatted: def neighbors4(point): "The four neighboring squares." x, y = point return ( (x, y-1), (x-1, y), (x+1, y), (x, y+1)) def neighbors8(point): "The eight neighboring squares." x, y = point return ((x-1, y-1), (x, y-1), (x+1, y-1), (x-1, y), (x+1, y), (x-1, y+1), (x, y+1), (x+1, y+1))
- skybrian 7y ago
  Well sure, but an automatic formatter can still be better or worse. Maybe it won't be as good as hand-crafted formatting, but more bad examples can be avoided.
- lysium 7y ago
  There is #format off for these few cases.
- hrktb 7y ago
  I don’t code in python so have no opinion on Black, but most code formatter can be adjusted to exclude some cases of formatting. I you would be fine with 95% of what it does and just want it to ignore the 5% where you care the most, I think the tool could benefit you. At least that’s how I feel about autoformatting in general.
  - akvadrako 7y ago
    Black is specifically designed to avoid being customizable, so you can't just exclude some cases.

photonios 7y ago

You could configure your IDE to re-format files into your favorite format and just have a pre-commit hook that formats them back into the official format. That's how I work. No arguments about style and formatting, yet I get to make the code look how I personally prefer it.

CrLf 7y ago
There is no such thing as "my favorite format" in that sense. Also, I don't mind reading code in other people's "favorite format" nor do I have any problem in following another person's style if that's the style agreed upon by the team.
a1369209993 7y ago
No, we can't. My (and, by the sound of it, CrLf's) favorite format relies on information that your pre-commit hook has artificially removed from the code. Eg: munge(gidget, thing1,thing2,thing3); cmplt(dtypeA,valueA, dtypeB,valueB); (Most cases are more subtle (and thus less amenable to "oh, you just need to build a complete static type checker into the formatter") than this, but I wanted an obvious example.)
- RussianCow 7y ago
  It seems like the signature of the functions should be different, especially the second example. I would have written the cmplt function to take tuple pairs: cmplt( (type_a, value_a), (type_b, value_b), ) That's much more clear about the relationship between each pair of values either way, and would get formatted nicely by Black.
  - a1369209993 7y ago
    Sorry, should have clarified: my example was written in C[0][1]; cmplt is something like (Dtyp* ,Dval* ,Dtyp* ,Dval* ), which is what I was alluding to with "just need a type checker". Also, in the code I anonymised that from, cmplt and munge are imported (well, #included) functions from a different library. 0: which doesn't have tuples anyway; you could use structs, but it doesn't really work well in context/practice. 1: I don't use python frecently enough to have ready examples of autoformatter stupidity on hand for it.

frosted-flakes 7y ago

> And some rules make this painfully obvious even in less subjective cases. Eg: black formats dictionaries into a single line if they fit one line, which makes nested structures unreadable if they combine bigger and smaller sub-dictionaries. Prettier for JS has a simple solution to this specific problem, and that is to follow the code's lead. If the first element of the object or array starts on the same line as the opening bracket, keep it as a single line if it fits. Otherwise, if the first element starts on a new line, put every element on a new line (explode the collection), even if they would all fit on a single line. Black should consider doing this instead of the open PR to explode collections if there is a trailing comma[0], which feels... wrong. [0] https://github.com/python/black/pull/826 https://github.com/python/black/pull/826