3 ms·

Golang has the right idea. There's an inbuilt language style and what you think matters doesn't because there's already a formatting tool and we'll all bend to

Golang has the right idea. There's an inbuilt language style and what you think matters doesn't because there's already a formatting tool and we'll all bend to it's will.

Groxx 4y ago
Black has been around a while and has pretty widespread use: https://pypi.org/project/black/ https://pypi.org/project/black/
- cricalix 4y ago
  Black is opinionated, but you just run it, accept the opinions, and never think about formatting after that. No debates over how to format a code block; focus on the actual logic being implemented.
  - fernandotakai 4y ago
    yup, after i embraced black, i can't go back (no pun intended) to not using it. it makes reading code so much easier.
- 6451937099 4y ago
  [dead]
- cauthon 4y ago
  It’s been a while since I’ve given black a shot, but I recall getting some really gnarly/ugly line wraps out of it and thinking it made the code less readable. I liked the idea but not the subjective style choices the devs made
  - Kwpolska 4y ago
    Black defaults to a line length of 88. While it is slightly larger than the old PEP8 standard of 79, and while it was chosen the intention of avoiding some ugly line wraps, it is still quite small and still leads to ugliness. Try raising the limit to a more reasonable 100-120 and see if it helps.
  - urxvtcd 4y ago
    The way I think about it is that if black's output looks weird, you should probably restructure your code. It's not _always_ true, but often enough it means the code can be made simpler, some values created in flight can be given names, and so on.
    - ttyprintk 4y ago
      Not saying there’s harm in realizing this, but the weirdest formatting choices in black seem to arrive deep in numerical formulae, where formatting actually makes differences in clarity. Under our typesetting-perfectionist overlords, our only recourse is to grow variable names so that the formulae make sense. And this defeats trying to reuse variable names from publication, so that a more-international audience can follow ‘ss’ rather than sum_of_squared_residuals_dude. Julia promotes this as a war cry over Python.
  - LtWorf 4y ago
    I mostly don't like how removing a parameter to a function can make it become 1 line, and then in the diff I have no idea of what has happened. In reviews I always ask that there must be a separate formatting commit, at the end. Also, because our builds fail if the code is not formatted, that means constant reformatting and moving around of commits. In the end the time wasted to start the container to run black (if you use the distribution one, every version formats differently), to run black (which is terribly slow), and juggle the commits around is hardly worth it. However I believe from a management perspective it gets rid of discussions about style in the reviews, so it looks like time is being saved because now the developers waste it each on their own in silence, without communicating.
    - ttyprintk 4y ago
      All your points are right in what I’d say is the most common ambient professional environment. We had an internal debate about how to gauge code quality. One camp only allowed the combination of black format plus coverage. To play devils advocate, I said that the number of asserts removed or added per merge request.
progbits 4y ago
Formatting is one small part of a style guide, and yes in every self-respecting place formatting is automated. What is then left is more interesting and important: naming, code organization, management of state, ...
masklinn 4y ago
Formatting is only a subset of style, there's plenty of questions it doesn't solve even in Go. Off the top of my head: value v pointer receivers, named return values, public fields v accessors, var v :=, in-band versus out-of-band signalling, closures in `go` statements (and even raw `go` statements at all), channel types, iface side-casting, etc...
- gonzo41 4y ago
  And generally my answer to all of that or both go and python is be consistent to yourself and to the codebase. And if you're going to change stuff in a big way. have a reason. And if you don't have a reason don't change.
  - masklinn 4y ago
    > And generally my answer to all of that or both go and python is be consistent to yourself and to the codebase. That's nice but not everybody thinks that way, and when the project gets big enough inconsistencies get introduced everywhere so there is no way to be "consistent with the codebase" unless you impose consistency via a style guide (and ideally a linter, so reviewers don't have to be the one performing style checking)

Golang has the right idea. There's an inbuilt language style and what you think matters doesn't because there's already a formatting tool and we'll all bend to it's will.

Groxx 4y ago

Black has been around a while and has pretty widespread use: https://pypi.org/project/black/ https://pypi.org/project/black/

cricalix 4y ago
Black is opinionated, but you just run it, accept the opinions, and never think about formatting after that. No debates over how to format a code block; focus on the actual logic being implemented.
- fernandotakai 4y ago
  yup, after i embraced black, i can't go back (no pun intended) to not using it. it makes reading code so much easier.
6451937099 4y ago
[dead]
cauthon 4y ago
It’s been a while since I’ve given black a shot, but I recall getting some really gnarly/ugly line wraps out of it and thinking it made the code less readable. I liked the idea but not the subjective style choices the devs made
- Kwpolska 4y ago
  Black defaults to a line length of 88. While it is slightly larger than the old PEP8 standard of 79, and while it was chosen the intention of avoiding some ugly line wraps, it is still quite small and still leads to ugliness. Try raising the limit to a more reasonable 100-120 and see if it helps.
- urxvtcd 4y ago
  The way I think about it is that if black's output looks weird, you should probably restructure your code. It's not _always_ true, but often enough it means the code can be made simpler, some values created in flight can be given names, and so on.
  - ttyprintk 4y ago
    Not saying there’s harm in realizing this, but the weirdest formatting choices in black seem to arrive deep in numerical formulae, where formatting actually makes differences in clarity. Under our typesetting-perfectionist overlords, our only recourse is to grow variable names so that the formulae make sense. And this defeats trying to reuse variable names from publication, so that a more-international audience can follow ‘ss’ rather than sum_of_squared_residuals_dude. Julia promotes this as a war cry over Python.
- LtWorf 4y ago
  I mostly don't like how removing a parameter to a function can make it become 1 line, and then in the diff I have no idea of what has happened. In reviews I always ask that there must be a separate formatting commit, at the end. Also, because our builds fail if the code is not formatted, that means constant reformatting and moving around of commits. In the end the time wasted to start the container to run black (if you use the distribution one, every version formats differently), to run black (which is terribly slow), and juggle the commits around is hardly worth it. However I believe from a management perspective it gets rid of discussions about style in the reviews, so it looks like time is being saved because now the developers waste it each on their own in silence, without communicating.
  - ttyprintk 4y ago
    All your points are right in what I’d say is the most common ambient professional environment. We had an internal debate about how to gauge code quality. One camp only allowed the combination of black format plus coverage. To play devils advocate, I said that the number of asserts removed or added per merge request.

progbits 4y ago

Formatting is one small part of a style guide, and yes in every self-respecting place formatting is automated. What is then left is more interesting and important: naming, code organization, management of state, ...

masklinn 4y ago

Formatting is only a subset of style, there's plenty of questions it doesn't solve even in Go. Off the top of my head: value v pointer receivers, named return values, public fields v accessors, var v :=, in-band versus out-of-band signalling, closures in `go` statements (and even raw `go` statements at all), channel types, iface side-casting, etc...

gonzo41 4y ago
And generally my answer to all of that or both go and python is be consistent to yourself and to the codebase. And if you're going to change stuff in a big way. have a reason. And if you don't have a reason don't change.
- masklinn 4y ago
  > And generally my answer to all of that or both go and python is be consistent to yourself and to the codebase. That's nice but not everybody thinks that way, and when the project gets big enough inconsistencies get introduced everywhere so there is no way to be "consistent with the codebase" unless you impose consistency via a style guide (and ideally a linter, so reviewers don't have to be the one performing style checking)