chipdart

> I agree that good engineers focus more on the actual structure and problems instead of nitpicky things like formatting

I don't think you understand that formatting is of critical importance.

Sure, your code won't break if you add a space at the right or at the left of a symbol.

But your code will be reformatted the next time someone like you works on that file and takes the same naive approach to that code that you took.

That leads to PRs having a larger code footprint for no reason other than fixing the previous PR's failure to comply with a style guide.

This means tools like Git blame start to flag parts of the code as having changed recently just because you failed to pay attention to the style guide.

Now that regression that was introduced by an unrelated commit becomes slightly harder to track because it's buried between commits that add and remove white spaces around the problem, and the last change is just nitpicking around something you should have gotten right in the very moment you posted your PR if only you ran a linter or paid attention to the comments posted in your PR.

> It's impossible for any code formatter to be 100%. Where to put a blank line? Where to break a line?

Not true. Those are objectively covered by any linter.

> How to name a variable/function?

Unless the issue is things like snake_case vs PascalCase, that's not the job of a linter. That's exactly what PR comments are about.

> Some try (e.g. prettier), and what you end up is frankly just bizarre code that's just ugly.

Not true. Without Prettier you always get bizarre code that's just ugly. You don't notice because you paid no attention to the code you wrote, it followed your personal subjective opinion you happened to have at that moment, and you didn't felt strongly enough to verify it.

Without a linter, others would certainly point out the problems they saw in your PR as that would certainly not comply with their personal subjective opinion they might hold at that moment and not before or after.

The importance of Prettier is that it objectively enforces a set of rules. If it's ugly it's because you configured it to be ugly, but it's less of a problem because it will be objectively, systematically and reproducibly ugly.

> Enforce a code quality standard with a linter and formatter and be done with it

Adopting a linter does not eliminate style issues. It just eliminates the number of possible comments a PR can get over style issues by replacing all detailed feedback with just one comment with a very clear actionable request that's trivial to satisfy: "It seems X doesn't look right. Could you please run the linter?"

> The PR feedback I give and receive is extremely influenced by the relationship I have with the person - for some PRs any nit pick feels frustrating (...)

Posting PR comments doesn't prevent you from accepting the PR. You can post a torrent of nit comments and still approve it so that minor issues don't turn into blockers.

> Reviews should not waste time with format - I would take the hour to set that up in CI and never worry about it again.

What if you post a PR and forgot to run a linter or configure your editor? Should that not justify a comment over style violations?

The problem will only go away if everyone is on the same page.

> I like this idea, it has the bonus of revealing how much the reviewer actually cares.

And now you contributed to turn your team culture into shit, with a toxic mix of PR creators purposely shitting on the team's style guide and PR reviewers who have to constantly post follow-up commits to your work because you can't even put together and acceptable PR or clean up after yourself.

What if anyone who posts a PR addresses feedback anyone posts on their work and addresses them until you get the necessary and sufficient approvals?

Services like GitHub and GitLab support preventing changes that overwrite a repo's history, in addition to tracking history even when you force update a branch.

> There is a lot of stuff a linter can't do (...)

Whatever a linter can't do, it's not worth doing.

> Naming being a big one.

You're confusing personal opinions over how to name things with concrete style issues.

> And any manager that lets it happen without severe reprimands to the time-waster isn't worth working for.

That would be something only a terribly incompetent manager would ever do.

A manager who is not terribly incompetent would either not take sides until explicitly asked to weigh in, and if and only if he was dragged into the discussion then the manager's only acceptable input would be to eliminate the problem for good by adopting a linter.

Everything else is a mistake and a complete waste of time.

> IMO the best way to handle stylistic choices (if at all) is to have the reviewer just adjust it themselves.

How does that inform the PR author that they failed to pay attention to a relevant detail, and more importantly contribute to not make it again?

If there is no feedback, problems will persist.

Nit comments add noise and failures to comply with a style guide is always a distraction on a PR, but that does not mean style guide violations should be ignored. It means that your team must work their way into making them a non-issue.

This means establishing an objective and usable set of rules and guidelines, and enforce them programmatically with a linter, not turning a blind eye to style violations.

> Is that new?

It's neither new nor novel. Even GitHub allows anyone to post a commit on a feature branch, regardless of who created it.

It's not a GitLab or GitHub feature. It's a Git feature: the ability to post a commit to a branch.

> over trivial style nonsense

What's your definition of "trivial style nonsense"? Is it "something I personally don't understand or care"?

Things like tabs vs spaces is important, and so is how many spaces an indentation level should take. This affects how editors reformat code, how other people's editors present the code, and even how many lines a commit has and is blamed for a change.

That's why linters are of critical importance to a team, and so is adopting a shared standard and editor config.

The only people who don't understand the importance of a style guide and how to make it a non-issue by enforcing tools to enforce it are those with little to no experience working with software.

> This is why I love things like cargo fmt / go fmt / eslint / etc.

I agree. Once I had the displeasure of working with a junior dev who was very prolific in posting comments on style and if a space should be at the left or at the right of a symbol. It took me a few days of dealing with that noise to onboard a linter.

Even so the junior dev felt entitled to manifest how high their standards were by posting a torrent of comments in the PR that onboarded the team's official linter config.

But once the PR was approved and merged, surprise surprise: the junior dev's PR comment metrics dropped from dozens per PR to zero. The style guide didn't even had to be enforced.

The last I've heard about the junior dev was throwing a tantrum when one of their PRs received a comment from another team member asking to run the linter because it failed to adhere to the team's official style guide. Apparently the high standards and this attention to detail only went one way.

> Most of it was stylistic nitpicking.

One man's "stylistic nitpicking" is another man's violation of the company's official coding guidelines.

Does the company adopted a linter? If so,why has the new hire not applied it before posting the PR?

Imagine a new hire throwing a hissy fit because even though the whole company writes code in PascalCase he feels that snake_case is better.

Imagine a new hire decided that tabs are better than spaces, and proceeded to reformat 30% of a source file leaving behind wonky indentation.

Shall we tolerate code that has both just so that random internet people in a random online forum can rail against PRs?

Or shall we post a comment in a PR pointing why the code should be reformatted?

> However, on the other hand, is it reasonable for a $5/month virtual machine customer to use 1Gbps 24/7/365, potentially consuming $100–$200 worth of bandwidth?

Irrelevant. If you sell a vCPU with enough bandwidth to feed your 1GBps 24/7/365 needs, and you charge $5/month for it, then it matters nothing what's your personal notion of reasonable. What matters is the service plan offered by the cloud provider and the performance indicators they are contractually obligated to meet.

You posted an advertisement, but you provided no reason for anyone to use this service.

Selling a service by running third-party software does not add value beyond what pretty much any cloud provider in the world already offers. In fact, this service sounds like a cloud provider with a very limited and narrow offer.

Why would anyone waste their time considering this service beyond pretty much any other alternative?

> But redis never had a foundation.

In theory Redis could have had a foundation. It didn't. Instead the project owner opted to sell it to a corporation. This doesn't happen by accident.

What indeed has a foundation is Valkey[1]. It's backed by the likes of AWS, Google Cloud, Digital Ocean, etc.

[1] https://www.linuxfoundation.org/press/linux-foundation-launc...

> But this is a takeover that is slowly draining the value from the community and directing it to private pockets. E.g. Redis is now source-available.

I think you're fooling yourself into believing that Redis was ever a community-owned project.

The truth of the matter is that the guy who developed Redis ended up selling Redis to a corporation. Since then he bailed out, and the corporation that owns Redis is now going through great lengths to monetize it.

The faster you forget about Redis and switch to alternatives, the better you'd be.

> That is a pretty dark view on almost 1/5th of humanity

The CCP does not represent 1/5 of humanity.

> and a nation with a track record of giving the world important innovations: paper making, silk, porcelain, gunpowder and compass to name the few.

Utter nonsense. It wasn't the CCP who invented gunpowder.

If you are willing to fool yourself into believing that somehow all developments that ever originated by people who live in a geographic region are due to the ruling regime, you'd have a far better case in praising Taiwan.

I do. I know that colors.js is a meme by now.

> Another 60,000 devices ripe for malicious entities to use in their botnet.

Right, my immediate reaction after reading the title was that D-Link might not patch their hardware, but others certainly will.

> Single file, 187 lines of JavaScript, no dependencies, does one thing and does it well.

Even though I understood your point, a cursory glance suggests it only maps a JavaScript object to a SVG. Hardly something with more than one responsibility, or something you need anything other than plain JavaScript to do.

> He compares it to the JS/TS relationship.

OP is right, TypeScript is a whole new syntax, and it's shtick is that it can be transpiled into JavaScript.

> Give these a try. I bet you'll like the results!

It sounds like too many words to refer ro plain old inversion of control and CQRS. They're both tried and true techniques.

> If your superiors are unable to process no-fluff information, regardless of whether it's feedback or updates, they have no business lording over anyone and will sink whatever function they have oversight of.

You're arguing based on how you think the world should be instead of how the world actually is.

> Denmark is not even close to jeopardizing its food supply, even less its food security. It produces way more food than is needed to feed its own population.

Denmark is a part of the EU. Their agricultural policy follows EU's common agricultural policy. Food security is evaluated accounting for all members, not individual member-states in isolation. In case of a scenario that puts food security at risk, such as an all-out war, it's in her best interests of all member states if the whole Europe can preserve it's food security.

> How does having such a large surplus (...)

You should educate yourself. Europe imports around 40% of the agricultural production it consumes.

The "surplus" is referenced in economical value and reflects luxury exports such as wine, which is hardly what keeps Europe alive in case of all-out war.

The whole point of Europe's common agricultural policy is food security including an event of all-out war.

Your comments sound like advocating against having a first-aid kit just because you sell silk scarves.

> Because it’s becoming increasingly obviously dumb to be paying farmers money to pretend like they are farming their land.

This is a particularly ignorant and clueless opinion to have.

The whole point of Europe's common agricultural policy is to preserve the potential of agricultural production as a strategic asset. Europe's strong economy and huge population density, coupled with cheap access to agricultural production from south America and Africa, renders most agricultural activity economically unfeasible. The problem is that this means Europe is particularly vulnerable to a blockade, and in case of all out war the whole continent risks being starved in a few months.

The whole point of EU's common agricultural policy is to minimize this risk.

Owners of farmland are provided a incentive to keep their farms on standby even if they don't produce anything exactly to mitigate this risk. It would be more profitable to invest in some domains such as, say, real estate. Look at the Netherlands: they are experiencing a huge housing crisis and the whole land in Holland consists of dense urban housing bordered by farm land. It would be tempting for farmers to just cash out on real estate if they didn't had an economic upside.

You would do better if you educated yourself on a topic before commenting on it.

> No, its because far lobbies are an important political block

Wrong. If you try to educate yourself, you will notice that EU's common agricultural policy even went to the extent of paying subsidies to small property owners to preserve their properties as agricultural land. This goes way beyond subsidizing production, or anything remotely related to your conspiracy theory.

Just because someone benefits from subsidy programs that does not mean that any conspiracy theory spun around the inversion of cause and effect suddenly makes sense. I recommend you invest a few minutes to learn about EU's common agricultural policy before trying to fill that void with conspiracies.

> Denmarks agricultural performance is not great at all. it's way too expensive to produce stuff. if it wasn't for EU subsidies the agricultural sector in Denmark would loose over 50% of their profits.

Agriculture in the EU is renowned for not being financially unjustified. For decades it's been a finantial no-brainer to import the bulk of agricultural products from south America and Africa. This is not new or the result of some major epiphany, it's the natura consequence of having an advanced economy and a huge population with high population density. The EU already imports 40% of the agricultural products it consumes.

EU subsidies were created specifically to mitigate the strategic and geopolitical risk of seeing Europe blockaded. Agricultural subsidies exist to create a finantial incentive to preserve current production capacity when it makes no finantial sense, and thus mitigate a strategic vulnerability.