Hacker News Reader

I found your comment insightful until the "(often substandard)" part. This betrays the rest of your comment. You start out saying how arguing specific indentation style is superficial but then betray this with that comment. If it truly is superficial then it does not matter what you lock in as long as you lock it in.

As with many things it's not actually a technical problem. It's a social problem. And it can work. Where I am right now for example we do have formatting locked in and enforced by linters. And it's not an issue there's no debate about it in regular PRs at all. The code formatter adjusts it and that's that. If you want to change it, create a PR that changes the rules and put a cross section of developers on said PR to discuss it. Happens from time to time but not often and works well.

I say "often substandard".... because, honestly, it just is. For example, breaking long logging lines into multiple lines decreases readability, but the formatter doesn't care because it only sees the max. line length and that's it. Same with breaking long function definitions: it doesn't consider what makes sense or what is readable, it just messes the code up. Similarly, some projects differentiate between single and double quotes (e.g. single quotes for data, double quotes for userstrings), and this just drives a tank over it.

Or completely disallow tabs, even when it's necessary for accessibility, like with screen readers (not even PEP8 enforces spaces, but black decides to without a configuration option)

Same with whitespace: it refuses you to add more than 1 (or 2, can't remember) empty lines inside a function, even when it would be more readable to space it out.

I heavily disagree with the assumption that consistency is better than readability. I believe that people can be civilised and not change each other's code just for the sake of formatting nitpicks, only when they actually edit the code.

Black not being configurable and getting popular is lame.

Every project should be able to argue once about style, what is important then just apply that going foward with a configurable style checker.

If it’s configurable, then it’s never settled. People will find reasons to want to change it, or someone new will come in that used a better config at their last job.

> People will find reasons to want to change it, or someone new will come in that used a better config at their last job.

This is fine. Discussing code style once in a while is not a problem. What's a problem is discussing it at every PR.

Having to endure through asinine style errors that no one in your team chose or even agrees with is worse than spending a couple hours every 6 months discussing a rule or two.

> Discussing code style once in a while is not a problem. What's a problem is discussing it at every PR.

I worked a team where this happened. Black was a godsend

That just means your coworkers are anti-social... this masks the problem but the real solution is educating people so they won't be anti-social anymore and stop nitpicking about others' style.

Teaching people to “just don’t be anti-social” is not the purview of people on a team trying to get work done, nor is it even possible in many or most cases.

The lack of debate over line-to-line code style (because it is enforced by a standard formatter) is one of the reasons I still enjoy using Go, and that's despite the fact that it doesn't use what was my preferred C-era brace style.

Just absolutely eliminating it as something to worry or argue about is something a lot more languages could benefit from, IMO.

And yes, while other languages have third-party formatting and linting tools that can enforce an agreed-upon standard, in the real world that just never works out as well (once a codebase grows beyond a couple of contributors) as having it be truly standardized in the language itself.

I think go has the benefit of the syntax being simple enough that not as much debate is needed. That is a legitimate feature of the language, and why not enjoy it. This comes already from the design of the language, I would say.

I'm comparing to Rust, and I'm not surprised that there are more different ways to format Rust and not always a way to make everyone happy.

> in the real world that just never works out as well (once a codebase grows beyond a couple of contributors)

Can you elaborate on this? Once you have a linter/formatter in your CI loop, how does it stop working just because you have more contributors?

My main project at work uses Elixir - which has a built in formatter - and Javascript - which doesn't. We use eslint for Javascript and haven't touched its config in years as devs come and go.

> From what I've seen so far, people love debating code style.

In my experience with people who seemed to confirm this, the opposite turned out to be true. I spent an inordinate amount of time configuring linting and formatting to suit their tastes, to minimize any formatting subjectivity in code review. Their reviews got a lot more substantive and valuable pretty much immediately because their formatting concerns were evidently close enough to solved that they could pay attention to what the code actually did.

I’ve had similar success adopting formatting that no one likes just because it’s opinionated and no one gets to dispute it because they couldn’t if they wanted to without diverting resources to a new tool. Now we’re all unhappy with the formatting and still happy to be reviewing actual substance.

When the bad formatting gets in the way, it’s trivial to ask the question “is this just a whitespace change?” and everyone groans for a second, agrees that it is, and gets on with life.

And when there’s any remaining style considerations (oh you like, or don’t like, reduce?) that’s a much smaller space of style concerns to negotiate and settle.

I think this is just accommodating anti-social behaviour, IMO. I think the correct choice of action is simply rooting the problem out by penalising comments about style on code review, so they focus on the substance of the code instead. Yes, this will require a period of uncomfortability while everyone gets used to each other's varied code styles, but it promotes a much more healthier atmosphere than the "suck it up" approach of unifying all code. That doesn't solve the problem, that just masks it by putting the code through a shredder so style gets lost.

A consistent style is useful. It doesn't matter much what it is, but consistency means you can jump into unfamiliar code and not get misled by a different style that makes some block not appear how it actually functions.

> penalising comments about style on code review

how exactly do you do that "penalising"?

The same way as you do it if people commit on the wrong branch, or commit SQL concatenated with plaintext, or if they are toxic towards a coworker...

I have a ton of code style preferences that I’m thrilled to put on the back burner to accomplish really much more important things with my team. I can express my individuality and let my whitespace and brace freak flag fly on personal projects, and I can even have more energy to get those adopted into core work if I want to, because my daily work isn’t burdened by formatting preference taking away from much more important concerns like whether the thing actually works, has acceptable performance and usability and accessibility characteristics, and can be maintained on a continuous basis.

It’s not that anyone else has felt stifled by this either. Everyone everyone contributing has welcomed the automated formatting dictator. We’ve all felt the benefit of not focusing review on stuff that doesn’t impact users.

If you really want to express yourself in code formatting, go wild on your own time and enjoy the free time you have for it by not putting it in the middle of otherwise meaningful work.

Code should not have personality. If you're working in a massive code base and people can tell you wrote code, that's probably an indictment on your code more than whatever style the company has chosen to use. Homogeneous code bases are the goal.

Only if you are an employer who wants to treat programmers interchangeably..... as a programmer, you have zero reason to do that. If all the codebase is homogenous, you can be replaced way easier, which is probably not what you want.

If your code style is what gives you the feeling of security at work… Well that’s a bit sad and I’m not convinced a linter can be blamed for anyone losing their jobs.

No, mostly not. Doing my job properly gives me job security for the most part - but this is one of the things where I don't see any benefit for yourself, there is only a benefit for your employer. Of course, I'm not advocating writing cryptic undocumented obfuscated mess (that's just plain unethical, even if it's "good" for you), but coding in a "standard" style just benefits your employer, not you. It just means you are more easily replaceable without any benefit for you. You won't learn more from doing it, you won't gain any skills or anything.

> It just means you are more easily replaceable without any benefit for you

What does this even mean?

Companies don’t (well, shouldn’t) hire developers to just write code. They hire them to solve problems. I’m not going to more easily replaced because my code follows the same styles as others, if I am the one solving the problems they have.

Yes, but others can also solve those problems. And if you make your code really standards-comforming, management will see that they could onboard another programmer really quickly. This is what you want to avoid.

Not to be mean or rude, but if we had a developer that was refusing to adhere to our standards, they not last long. Being able to produce code in agreed upon standards is table stakes.

Sure, and I'll agree to accept the standards. I'll follow them most of the time. Except when I "forget".

Ah, I see now, you’re a troll. That should have been obvious earlier…

I am not a troll, I just don't do things which actively work against me.

You would not last long in my team. When you “forget” the standard, you would have to rewrite your code. In the end you would perform a lot worse than other team members.

Anyone should be able to follow coding standards, you do not have to be smart for that. You just have to be able to put aside your ego and follow what the team is doing. I am a lot more forgiving to people making mistakes than to people forgetting the coding style.

And anyhow, I enforce the code style by making sure the code simply does not build if you do not follow it.

Absurd view. At least try to be professional.

> If all the codebase is homogenous, you can be replaced way easier, which is probably not what you want.

That's exactly what you want, unless your goal is to have job security rather than building something.

I definitely agree that Black (which I love) is pretty overrated in the number of problems people think it will solve for them. But I just don't get this view

> removes any kind of personality from the code

What kind of personality comes from things like pefering " over '; having tabs over spaces; having n spaces between class methods?

For me, those things are essentially meaningless but nice to have consistency on. Code personality, and a large part of readability comes from things like: - variable / class names - functional vs oop problem solving - type use - custom data structures or not etc

None of those have are locked down or touched by a lint tool like Black. Use it or don't, but you'll have plenty of personality in your code either way.

"Consistency is the most important" seems to be an axiom...

"having n spaces between class methods" is definitely *not* meaningless. It affects code readability and black has very opionated (and often inappropriate) ideas about what counts as "readable" whitespace. When you raise that problem with people, they always say "well too bad, you should write shorter functions instead", which just introduces another layer of opinionatedness.

That's not the interesting "personality". I think the formatting tools bring in something completely different: code layouts that you would never write by hand.

I don't like that. Code should be a transparent interface, you write something and it becomes part of the program. With code formatting it becomes, you input something into the source code, you transform it with the tool, and then it's done. We sort of lose the brain-hand-program connection.

As an example I randomly found this code snippet of rust imports. To reproduce this by hand would be like writing JSON by hand - I'm referring to the nesting, bracketing and sorting. This is the lack of personality: no longer writing code by hand, but with tools.

    use core::fmt;
    use std::{
        alloc::{GlobalAlloc, System},
        cell::UnsafeCell,
        cmp,
        fmt::Write,
        marker::PhantomData,
        sync::{
            atomic::{AtomicBool, Ordering},
            Mutex,
        },
        time::Duration,
    };

    use serde::{
        de::{self, SeqAccess, Visitor},
        Deserialize, Deserializer, Serialize,
    };

>A very common thing I see nowadays is a forced adoption of gofmt/black/whatever, hoping it would solve the obsession with the formatting. However, this just locks in a (often substandard) coding style and removes any kind of personality from the code. This is good if you are a manager trying to treat your employees as fungible units of work, but is bad for actually maintaining a codebase. Also, it doesn't stop obsession with style, it just forces a specific style on everyone which most of the time, everyone slightly hates.

This is so wrong. There is no reason to not have a standart for formatting code when working in a team.

There are good reasons for not having a standard code formatting style in a team. They might be ones you don't agree with, but saying there are no good reasons is IMO a bit disingenuous. With mature team members, it's perfectly possible to respect each other's style and if executed well, it can have advantages such as being able to very quickly identify who wrote something (who to pester about something), making readability decisions locally instead of globally and benefits like that.

Of course, that requires a team with emotional maturity, which is I get, not very common in the software industry.

Reading this and your other comments I have two very conflicting vibes that I:

1. Hard disagree on the idea of multiple styles in a single codebase and think being able to identify writers of code by style rather than version control sounds like madness incarnate.

2. Massively want to read a blog post or something from you about your ideas on code style. Sounds like you have some pretty valid and well thought out ideas justying a philosophy of code style I've never heard supported before (I think normally disparate code styles in a code base would get interpreted as a code smell rather than a positive)

Hi! I don't have a website or a blogpost or anything, to be honest. If you want to chat about it, I'm happy to - my Discord is on my profile, my email is prisznyak.zsombor@gmail.com , or if you want to communicate with some other platform, let me know.

Better edit the comment and remove the email, as it can be scanned by crawlers and added to a spam list.

Imo, just sounds like someone mad that others can't recognize their "style" when reading code that's been through a formatter.

Code is not just for style. You get no points for fancy spacing. You get no money for having being a "that guy who likes to format his args weirdly".

If style didn't matter at all, we'd be writing assembly or bytecode. But we don't, because code is written for humans most importantly. Reducing the code down to basically the AST makes it lose important semantic meaning; which defeats the purpose of high-level languages.

I suppose you never encountered git conflicts caused by differences in the autoformatter settings.

Or a lot of changes without reason, making it more time consuming to find the real change in the commit diff log.

I don't mind differences in code style. There is a standart called editorconfig, which IDEs support, which makes code style rules IDE independent.

Actually if you have people with experience and professionals, they don't care about a specific code style rule, they don't care if they switch the code style from project to project, they just want a standart set of rules for the whole team so that there are no issues caused by different formatting styles.

> it just forces a specific style on everyone which most of the time, everyone slightly hates.

Just stop caring about useless stuff, gee… this is what the code review pyramid about, focus your efforts and care on important stuff, not irrelevant details.

Auto formatted code is the best thing that happened in the last few years. I don’t care that it doesn’t show the « personality of the dev who wrote it », I want consistent code.

> but is bad for actually maintaining a codebase

Absolutely not.

Unfortunately, variable naming is one of the most important parts of writing software.

> However, this just locks in a (often substandard) coding style and removes any kind of personality from the code. This is good if you are a manager trying to treat your employees as fungible units of work, but is bad for actually maintaining a codebase.

Is it bad, though? Having most of the code in the codebase look and read consistently feels like a good thing, even if that's not the style that you'd personally prefer. Especially if the formatter does its thing whenever you save a file.

If you want to be treated interchangeably to everyone else in the industry, yes. Otherwise, I don't think that's a good thing for you as a programmer

it's a classic bike shedding exercise: https://en.wikipedia.org/wiki/Law_of_triviality

But we _are_ fungible. At least 99% of developers in 99% of projects.

Management is right in trying to remove “personality” imo.

I mean, you are right.... But as programmers, shouldn't you try to be less replaceable? Have unique skills or methods which can be valued, instead of being a generic hotswappable code monkey.

I don't really understand your logic - why is management right for removing personality? Of course, from a programmer's perspective, not from the manager's perspective.

Being able to use generic hotswappable code monkeys would be the wet dream of corporate executives. Imagine being able to scale or shrink your dev work force on demand, as if we were AWS instances. Actually this is the selling point of companies like Accenture or Globant, no wonder they have been so successful.

From a dev pov, making sure you are easily replaceable means that you could also find a new job easily. So it’s not all bad.

black is brilliant and should be used on all Python projects.