Hacker News new | past | comments | ask | show | jobs | submit
dewey | on: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it. That's the whole point of code style guidelines like that as there's no functional reason for them.

That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) doesn't even cross anyones mind.

phoghed | parent | next
Waiting patiently for the other person to produce a post hoc rationalization about why everybody’s code looking different is in fact a good thing
maratc | root | parent | next
My argument is more to the tune of "everybody’s code looking slightly different is not a problem in practice as long as I can read and understand it."

However since you've asked so nicely here you go: everybody’s code looking different is because all humans are different. It's what makes us human. I am very serious about my craftsmanship, and I bring my "humanity" to it: sometimes I include a cultural reference (as in the example above), or an internal joke in the name of a (very long) variable, or vent my frustration in a comment.

My first ten years of writing Python were uneventful; nobody commented about my style and I never commented about others'. With the advent of grammar nazi bots, everyone is supposed to now please them by writing completely bland code, which in my opinion degrades me from a craftsman to a code-monkey. This is dehumanising, in a certain sense.

refactor_master | root | parent | next
But your choice of funny variable names is not a craft, and you’re not a craftsman if you think it matters. What matters is extensibility, maintainability and value delivered.

I care how the food tastes, not that the chef has a really cool Japanese knife and is really fast at cutting onions.

loading story #49058001
loading story #49058027
jghn | root | parent
I'd go so far as to argue that person to person differences are helpful to a reader. When I am dealing with a long term code base it's easy to develop a feel for who is responsible for different constructs without needing to rely on the git history. This gives me immediate information on what to expect.
insanitybit | root | parent | next
Can you not read code if it uses single vs double quotes?
9dev | root | parent | next
I can - in fact, I have to, a lot more than I'd like - when someone makes changes with different code style settings in their IDE or tooling, and that affects unrelated parts of the code, and suddenly the PR contains tons of code that just looks subtly different but still does the same thing.

If sieving the spam from ham in code reviews is your thing, go have fun.

I personally prefer code that is automatically and unconditionally kept in the exact same shape, preserving only the intended changes to stop the team from wasting time on formatting or reviewing.

loading story #49057637
dewey | root | parent | next
You are not making the strongest point by using a relatively subjective rule like that. It includes indentation, how to structure functions and the parameters and many more that in sum make it very easy to jump between projects (Internal company projects, dependencies, other open source projects) without ever getting used to a new style. This makes reading and contributing very easy.

Compare that with other languages where you need to load a different set of prettier rules, code formatting tools and follow contribution guidelines on how things should look like depending on the opinion of the maintainers.

loading story #49057656
yread | root | parent
That's exactly what a good cogwheel in the machine would say
coldtea | parent | next
>Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it.

Which might be more overrated OCD than anything worth it. If you like that, you can add a formatter at the end of the chain or even just when reviewing.

kristjansson | parent | next
The value isn't just in the lack of discussion, but in amplifying the signal to noise ratio of diffs. with ruff or gofmt or whatever, it’s pretty much guaranteed that a change of code is an intentional part of the proposed change. with multiple authors with variable code styles touching the same project, there is a much higher chance of a diff containing lines that preserve semantics but change the code.
CrompyBlompers | parent | next
There's a ton of variation in golang code, as gofmt is not opinionated enough. As evidenced by the existence of golines[0] or gofumpt[1].

0: https://github.com/golangci/golines/

1: https://github.com/mvdan/gofumpt

sennalen | parent | next
Is that really a problem that needs solving though? The easiest way to not spend time bikeshedding is to just not bikeshed. Don't make guidelines. Don't run tools to check them. Don't comment on them in PRs. None of it matters.
kstrauser | root | parent
Historically, yes. At some point, one person who likes to work with narrow terminal windows gets fed up with long lines and starts reformatting stuff as they go. Another person with a widescreen editor hates looking at code clustered around the left edge of the screen gets fed up and starts reformatting stuff as they go. It's just a mess. You end up with PRs where it's hard to see the 3 things that changed because it contains 200 lines of "my IDE would prefer to format things this way instead".

I have never seen this not happen, barring using autoformatters. I think Go and Rust have had great success avoiding all these dumb arguments by having built-in opinionated formatters from nearly the beginning.

loading story #49061577
jghn | parent
> That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) doesn't even cross anyones mind

I remember people saying this exact same thing about Python ~20 years ago.