5 ms·

I'm not a big fan of automatic code formatters, unless they get somewhat more configurable. One simple example is line length. Usually a code formatter will bre

I'm not a big fan of automatic code formatters, unless they get somewhat more configurable. One simple example is line length. Usually a code formatter will break long lines, for example a function call with some arguments. But what if I have a log call there? Do I want to have that log span 3-6 rows, just because the silly formatter thought it is a long line? Well it is a long line, but I don't want to break it into multiple lines, as that would give that log call waaaay too much space. When the log call spans multiple lines, it distracts from the bits of code between log calls. Another example is, that these code formatters are often configured wrongly in people's code editors to reformat everything in the whole file. That adds lots of changes and people do not afterwards separate their commits for "only reformatting" and the actually important bits of their changes. As PEP8 already says: "A Foolish Consistency is the Hobgoblin of Little Minds". An automatic code formatter is the epitome of consistency, as it applies the rules everywhere the same way. In many places it might give some benefits, but in others it will ruin the original code formatting. I am experienced enough to format my code in a readable way and I don't need it reformatted, just because someone has to try out some tool. Especially log calls. Those are a pet peave of mine.

heavenlyblue 5y ago
> Do I want to have that log span 3-6 rows, just because the silly formatter thought it is a long line? Yes. I do not understand what’s wrong with it. Code formatting is a political stance. It’s so much easier to adopt that than have everyone have slightly different opinions on how things should be formatted.
- zelphirkalt 5y ago
  So my function of 3-4 lines actual code with log lines in between (so maybe 8 lines) becomes a function of 20 lines, because of the code formatter changing those log lines and putting every argument on a new line. Now the function takes two third of my screen and I cannot scan it as quickly with my eyes any longer. I cannot simply skip log lines, but need to check for the end of the log calls instead. No thanks.
  - xigoi 5y ago
    Fold the lines with logs. Problem solved.
    - zelphirkalt 5y ago
      That's actually an idea. Gonna try that out next time I have this problem. I just hope that there is some way to automatically fold. I will also need to get a good keybinding in place for unfolding, in case I do want to read that log line.
      - xigoi 5y ago
        >I just hope that there is some way to automatically fold. Depends on your editor. Vim can definitely do it.
  - patrick451 5y ago
    This is also one of my gripes with black. I'm pretty sure whoever wrote was getting paid per line of code. So we got an auto-formatter than optimizes for maximum line count.
  - heavenlyblue 5y ago
    > Now the function takes two third of my screen and I cannot scan it as quickly with my eyes any longer. You should be able to scan is as fast because ignoring the 3 lines with additional spacing is easy.
- tayo42 5y ago
  > It’s so much easier to adopt that than have everyone have slightly different opinions on how things should be formatted. Cant this be done with just a linter to enforce some rules without forcing an auto format. I really liked just working with a linter to enforce style, as long it passed everything was fine. But still left some room for the coder to make things readable
  - heavenlyblue 5y ago
    “Readable” is equivalent to “I am used to reading code like that” rather than “there is some idealised metric that defines readability” You are mistaking your own habits for your rationality
    - tayo42 5y ago
      I don't think that's true otherwise I would never be able to improve my codes readability. I have received suggestions that make code better to read and have read others code that I found to be neater. If it was just my habits then everything written by other people would always be harder to read
lr4444lr 5y ago
I agree on the need for configurability, but the counterpoint is that on a team of devs where everyone has their own IDE auto formatting activated, applying this to the whole file just for a tiny logical change would create a lot of VCS noise. Autoformatters ensure that what makes it into the master branch has no surprises.
- zelphirkalt 5y ago
  Just have no automatic formatting and have a good consensus agreed upon. I like to write ";" in JS for example, like in old times. I find it more explicit. However, I made a compromise for one project, where people had started out without ";" at the ends of lines. Sometimes you have to make compromises. If no one is automatically code formatting, then no such noise is created. You could even get a linter telling you about PEP8 violations by underlining stuff for example and configure an exception list for the linter, which is company wide, but not have any automatic change happening. The worst offender is automatic code formatting at commit time. You think you commit one thing, but the formatter commits another.
  - solarmist 5y ago
    > Just have no automatic formatting and have a good consensus agreed upon. Wow, I wish I lived in your world. I've never see a team larger than 3 people have a consensus on code formatting.
  - sateesh 5y ago
    Even if a good consensus is agreed upon how to enforce it in a team of (10 devs, say). So agree on a consensus black format and run as a pre-commit check before merge to master.
alexjurkiewicz 5y ago
The key part of your message is "I am experienced enough to format _my_ code in a readable way". It's not a tradeoff between "good manual formatting" and "mediocre automated formatting". It's a tradeoff between "random formatting" and "consistent formatting". Manual formatting only works when a dictator spends their time enforcing a consistent style. Once projects get large, the value of this is marginal.
- deleted 5y ago
  [deleted]
brandmeyer 5y ago
<salesman voice>Black's strictness getting you down? Try autopep8: The flexible Python formatter!</> Its fast enough, can be made to run incrementally, has enough configuration options, and accepts a project-specific configuration file. There is room for a solution in-between laissez-faire and black's strictness.
solarmist 5y ago
Sure, but I care a LOT more about avoiding style battles with others than not having my ideal code formatting. And not having to think about it at all is just an additional bonus. I used to have to make style passes before I would commit code. And get style comments in code reviews. I don't miss those days.
- MereInterest 5y ago
  The popularity of black makes it a Schelling point [0]. It's not my favorite code style. At some point before the enum module was added, I picked a habit of using single-quote 'strings' for internal fixed strings and double-quote "strings" for human-readable messages. Black's formatting of strings to all use double quotes removes this distinction. But having some 95% solution can get 95% of people to agree to it, which is enough to avoid arguments that never reach a conclusion. [0] https://en.wikipedia.org/wiki/Schelling_point https://en.wikipedia.org/wiki/Schelling_point
  - solarmist 5y ago
    Oh cool! I hadn't heard of that.
    - MereInterest 5y ago
      It's a really fun concept that helps explain and understand a lot of politics. That positions held by groups don't need to be internally consistent in the same way that an individual's positions (ideally) should be. For a group, they main instead represent a mutually agreeable compromise between internal divisions of a group. Sort of like how if you're ordering pizza for a group of friends, a safe bet would be to order two pizzas, one pepperoni and one veggie. It's not going to be everybody's favorite pizza, or may not be anybody's favorite pizza, but most groups wouldn't be too put off by the selection.
  - Qub3d 5y ago
    Interesting, Black docs specifically calls out an option for users with that exact use case for mixing single and double-quoted strings (although they do recommend dispensing of it eventually): https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#strings https://black.readthedocs.io/en/stable/the_black_code_style/... > If you are adopting Black in a large project with pre-existing string conventions (like the popular “single quotes for data, double quotes for human-readable strings”), you can pass --skip-string-normalization on the command line. This is meant as an adoption helper, avoid using this for new projects.
stonecharioteer 5y ago
I think today's Python has long surpassed it's PEP8 edicts. There is no longer one and only one obvious way of doing things, which is not just sad but downright becoming a hazard for entry into the language. I cannot imagine being a newcomer anymore, as compared to the days where you'd read a book like Zed Shaw's Learn Python the Hard Way and get started. It's sad.
- zelphirkalt 5y ago
  However, if one is a beginner, I think others in that environment should not put too much emphasis on formatting being exactly correct. Maybe drop a note when talking about the code or mentoring, but don't make it the main point, when there are probably many more significant things to focus on with code of a beginner. Maybe starting out has not become that much different then.
midrus 5y ago
That's the whole point of a code formatter. To avoid these bike shedding discussions and get back to work. Where you think a long call should be allowed somebody else will think it should be split. Pick a code formatter, and fuck opinions, we'll do whatever the formatter says we have to do. Done. It is not that important if you put semicolons here or there as long as it is consistent.

heavenlyblue 5y ago

> Do I want to have that log span 3-6 rows, just because the silly formatter thought it is a long line? Yes. I do not understand what’s wrong with it. Code formatting is a political stance. It’s so much easier to adopt that than have everyone have slightly different opinions on how things should be formatted.

zelphirkalt 5y ago
So my function of 3-4 lines actual code with log lines in between (so maybe 8 lines) becomes a function of 20 lines, because of the code formatter changing those log lines and putting every argument on a new line. Now the function takes two third of my screen and I cannot scan it as quickly with my eyes any longer. I cannot simply skip log lines, but need to check for the end of the log calls instead. No thanks.
- xigoi 5y ago
  Fold the lines with logs. Problem solved.
  - zelphirkalt 5y ago
    That's actually an idea. Gonna try that out next time I have this problem. I just hope that there is some way to automatically fold. I will also need to get a good keybinding in place for unfolding, in case I do want to read that log line.
    - xigoi 5y ago
      >I just hope that there is some way to automatically fold. Depends on your editor. Vim can definitely do it.
- patrick451 5y ago
  This is also one of my gripes with black. I'm pretty sure whoever wrote was getting paid per line of code. So we got an auto-formatter than optimizes for maximum line count.
- heavenlyblue 5y ago
  > Now the function takes two third of my screen and I cannot scan it as quickly with my eyes any longer. You should be able to scan is as fast because ignoring the 3 lines with additional spacing is easy.
tayo42 5y ago
> It’s so much easier to adopt that than have everyone have slightly different opinions on how things should be formatted. Cant this be done with just a linter to enforce some rules without forcing an auto format. I really liked just working with a linter to enforce style, as long it passed everything was fine. But still left some room for the coder to make things readable
- heavenlyblue 5y ago
  “Readable” is equivalent to “I am used to reading code like that” rather than “there is some idealised metric that defines readability” You are mistaking your own habits for your rationality
  - tayo42 5y ago
    I don't think that's true otherwise I would never be able to improve my codes readability. I have received suggestions that make code better to read and have read others code that I found to be neater. If it was just my habits then everything written by other people would always be harder to read

lr4444lr 5y ago

I agree on the need for configurability, but the counterpoint is that on a team of devs where everyone has their own IDE auto formatting activated, applying this to the whole file just for a tiny logical change would create a lot of VCS noise. Autoformatters ensure that what makes it into the master branch has no surprises.

zelphirkalt 5y ago
Just have no automatic formatting and have a good consensus agreed upon. I like to write ";" in JS for example, like in old times. I find it more explicit. However, I made a compromise for one project, where people had started out without ";" at the ends of lines. Sometimes you have to make compromises. If no one is automatically code formatting, then no such noise is created. You could even get a linter telling you about PEP8 violations by underlining stuff for example and configure an exception list for the linter, which is company wide, but not have any automatic change happening. The worst offender is automatic code formatting at commit time. You think you commit one thing, but the formatter commits another.
- solarmist 5y ago
  > Just have no automatic formatting and have a good consensus agreed upon. Wow, I wish I lived in your world. I've never see a team larger than 3 people have a consensus on code formatting.
- sateesh 5y ago
  Even if a good consensus is agreed upon how to enforce it in a team of (10 devs, say). So agree on a consensus black format and run as a pre-commit check before merge to master.

alexjurkiewicz 5y ago

The key part of your message is "I am experienced enough to format _my_ code in a readable way". It's not a tradeoff between "good manual formatting" and "mediocre automated formatting". It's a tradeoff between "random formatting" and "consistent formatting". Manual formatting only works when a dictator spends their time enforcing a consistent style. Once projects get large, the value of this is marginal.

deleted 5y ago
[deleted]

brandmeyer 5y ago

<salesman voice>Black's strictness getting you down? Try autopep8: The flexible Python formatter!</> Its fast enough, can be made to run incrementally, has enough configuration options, and accepts a project-specific configuration file. There is room for a solution in-between laissez-faire and black's strictness.

solarmist 5y ago

Sure, but I care a LOT more about avoiding style battles with others than not having my ideal code formatting. And not having to think about it at all is just an additional bonus. I used to have to make style passes before I would commit code. And get style comments in code reviews. I don't miss those days.

MereInterest 5y ago
The popularity of black makes it a Schelling point [0]. It's not my favorite code style. At some point before the enum module was added, I picked a habit of using single-quote 'strings' for internal fixed strings and double-quote "strings" for human-readable messages. Black's formatting of strings to all use double quotes removes this distinction. But having some 95% solution can get 95% of people to agree to it, which is enough to avoid arguments that never reach a conclusion. [0] https://en.wikipedia.org/wiki/Schelling_point https://en.wikipedia.org/wiki/Schelling_point
- solarmist 5y ago
  Oh cool! I hadn't heard of that.
  - MereInterest 5y ago
    It's a really fun concept that helps explain and understand a lot of politics. That positions held by groups don't need to be internally consistent in the same way that an individual's positions (ideally) should be. For a group, they main instead represent a mutually agreeable compromise between internal divisions of a group. Sort of like how if you're ordering pizza for a group of friends, a safe bet would be to order two pizzas, one pepperoni and one veggie. It's not going to be everybody's favorite pizza, or may not be anybody's favorite pizza, but most groups wouldn't be too put off by the selection.
- Qub3d 5y ago
  Interesting, Black docs specifically calls out an option for users with that exact use case for mixing single and double-quoted strings (although they do recommend dispensing of it eventually): https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#strings https://black.readthedocs.io/en/stable/the_black_code_style/... > If you are adopting Black in a large project with pre-existing string conventions (like the popular “single quotes for data, double quotes for human-readable strings”), you can pass --skip-string-normalization on the command line. This is meant as an adoption helper, avoid using this for new projects.

stonecharioteer 5y ago

I think today's Python has long surpassed it's PEP8 edicts. There is no longer one and only one obvious way of doing things, which is not just sad but downright becoming a hazard for entry into the language. I cannot imagine being a newcomer anymore, as compared to the days where you'd read a book like Zed Shaw's Learn Python the Hard Way and get started. It's sad.

zelphirkalt 5y ago
However, if one is a beginner, I think others in that environment should not put too much emphasis on formatting being exactly correct. Maybe drop a note when talking about the code or mentoring, but don't make it the main point, when there are probably many more significant things to focus on with code of a beginner. Maybe starting out has not become that much different then.

midrus 5y ago

That's the whole point of a code formatter. To avoid these bike shedding discussions and get back to work. Where you think a long call should be allowed somebody else will think it should be split. Pick a code formatter, and fuck opinions, we'll do whatever the formatter says we have to do. Done. It is not that important if you put semicolons here or there as long as it is consistent.