I’ll go a step further.

I’ve never understood why people care so much about the linter. Just let people write code and don’t worry about the linter. I don’t need to fight a linter which makes my code worse when I could just write it in a way that doesn’t suck. I promise it’ll be fine. I’m too busy doing actual software engineering to care if code is not perfectly formatted to some arbitrary style specification.

I feel like style lingers are horseshoe theory. Use them enough and eventually you wrap back around to just living without them.

▲ ngruhn 4 days ago | parent | next [-]

Why is this flagged? I completely agree.

99% the linter is not enforcing correctness in my experience. It's just enforcing a bunch of subjective aesthetic constraints. Which import order, max number of empty lines between statement, what type of string literal to use, no trailing white space, etc. A non trivial part of my day is spent dealing with this giant catalog of dinner etiquette. Not all of it is auto fixable. Also, there are plenty of situations where everyone would agree that violating the rule is necessary (eg. "no use before define" but you need mutual recursion). Also sometimes rules are circularly in conflict (eg you have to change a line but there is no way to do it without violating the max-line-length rule).

	▲	MrJohz 4 days ago \| parent \| next [-]
		If your linter is enforcing subjective aesthetic constraints, then I'd argue it's not really a linter but a formatter at that point, and it should be automatically fixing all that stuff for you rather than have you do that manually. Things like import order, empty lines, white space etc can all be fixed automatically in most languages I've worked with. Linters enforcing rules that need to be broken is a pet peeve of mine, and I agree with you there. Most linters allow for using comments to explicitly exclude certain lines from being linted. This should ~never be necessary. If it is regularly necessary, then either you're programming bad (always a possibility!) or the rule has too many false positives and you should remove it.
	▲	komali2 4 days ago \| parent \| prev [-]
		Does your linter not have a fix command for things like import order? Does your editor not auto trim white space? To be frank, everyone I've worked with that complained about the linter didn't know much about their tooling. They didn't know about the fix command (even though I put it in the readme and told them about it), they didn't know how to turn on lintfix and prettier on save, wouldn't switch on git hooks and didn't know their lint failed until GitHub said so, and none of the people like this were so productive that it made up for this trait.

▲ skinner927 4 days ago | parent | prev | next [-]

The point of linters is so the code looks the same regardless of who wrote it. This way it’s easier to read. Some people have horrible style and linters really help.

I find linters make me faster. Sometimes I’m feeling lazy and I just want to pump out a bunch of lines of ugly code with mappings poorly formatted, bad indents, and just have it all synched up when I save.

▲

carlosjobim 4 days ago | parent [-]

I see no reason to accommodate to worthless programmers who aren't able to read or format the code that's sent to them. They can lint it themselves if they want.

▲

mindwok 4 days ago | parent [-]

It's not about accomodating people, it's about consistency in codebases when many people with different preferences or styles are working on it. You just eliminate the cognitive overhead so people can develop intuition about how the code works and flows.

	▲	carlosjobim 4 days ago \| parent [-]
		Good, let huge companies do that. Now this lint madness is pushed onto everybody who wants to program, including individual hobbyists. And many of them are trying to learn coding and get their compiling sabotaged by the linter, not knowing it's something they can opt out of.

▲ pletnes 4 days ago | parent | prev | next [-]

Some linters find issues you care about. Forgotten print statements or confusing indentations come to mind. I’ve worked with people who easily forget, and I’m one of them myself.

	▲	4 days ago \| parent [-]
		[deleted]

▲ tacitusarc 4 days ago | parent | prev | next [-]

That may be true for you, but I have worked with plenty of devs who cannot even be consistent with naming conventions in a function, let alone throughout the application.

Don’t get me wrong: modern liners often annoy me and devs who spend a lot of time fiddling with those settings tend not to be very good programmers. But sometimes having guardrails is necessary.

▲ thfuran 4 days ago | parent | prev | next [-]

Everyone has their own opinion of what format doesn’t suck, so without a consistent code format, you’ll have to review diffs where fights over white space are mixed in with the meaningful change.

▲ jwilber 4 days ago | parent | prev | next [-]

But what’s the issue? Setting lint rules is one and done - running pre-commit can be made automatic?

▲ maratc 4 days ago | parent | prev | next [-]

Agree.

There's a python linter named `black` and it converts my code:

    important_numbers = {
        "x": 3,
        "y": 42, # Answer to the Ultimate Question!
        "z": 2
    }

into this:

    important_numbers = {"x": 3, "y": 42, "z": 2}  # Answer to the Ultimate Question!

This `black` is non-configurable (because it's "opinionated") and yet, out of some strange cargo cult, people swear by it and try to impose it on everybody.

▲ iainmerrick 4 days ago | parent | next [-]

This is the flip side of "I’ve never understood why people care so much about the linter"!

Why are you caring about formatting? Just write your code, get it working, let Black tidy it up in the standard way. Don't worry about the formatting.

In cases where you're annoyed about some choice the formatter makes, somebody else would be equally annoyed by the choice you would rather make. There is no perfect solution. The whole point is to have a reasonable, plausible default, and to automate it so that nobody has to spend any time thinking about it whatsoever.

Running a standard formatter when code is checked in minimizes the source control churn due to re-formatting. That churn is a pointless waste of time. If you don't run a standard formatter, I guarantee that badly-formatted code will make it into source control, and that's annoying.

▲ maratc 4 days ago | parent | next [-]

I may be unusual in a way I treat my profession and care about my professional output (the code I write), and I take both very seriously.

There's a quote from Steve Jobs (or maybe his carpenter father):

    “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

When you say "Don't worry about the formatting", what you're saying is "use a piece of plywood on the back," and I'm just not going to do that.

▲

iainmerrick 4 days ago | parent [-]

I don't think we'll ever fully agree, but I'd just like to clarify that I value that kind of craftsmanship too!

I just honestly believe that if you fully automate the formatting, the results are better than if you do it painstakingly by hand; better by virtue of being more consistent. It's using the right tool for the job.

▲

tacitusarc 4 days ago | parent [-]

Did you read the example pietnas gave? The changed formatting ruined the communicative intent of his code. Formatters do that a lot, and it makes the code unambiguously worse.

I don’t really care about whether the back is plywood or whatever. I don’t know how to write plywood code. I do care about creating clear, readable code that communicates my intent. Sometimes formatters help with that. Often they hinder, as they reflect the arbitrary aesthetic preferences of their creators.

▲

iainmerrick 3 days ago | parent [-]

I don't see "pietnas" anywhere; do you mean the "important_numbers" example from maratc?

If so, I think a trailing comma is the correct fix, as described here: https://news.ycombinator.com/item?id=45168308

In this case I think the trailing comma is an improvement, so the formatter is steering you towards a better overall solution. However, even if you dislike the trailing comma, it's more important for the formatting to be consistent and robust, so I still think it's better to work within the limitations of the formatter.

	▲	tacitusarc 2 days ago \| parent [-]
		I honestly have no idea where I read pietnas. The comment you identified was the one I was referring to. I care about consistency, but not foolishly so. I suppose an important question is: under what circumstances is consistency undesirable? I believe that consistency is not an end goal, but a means to achieve clear communication. When being consistent results in less clarity, it should be abandoned in favor of more effective communication.

▲ thfuran 4 days ago | parent | prev [-]

That’s an obviously terrible formatting change. A format that prevents scoping comments narrowly is absurd. Why not just tuck all the inline comments at the end of the file so the code is denser while we’re at it?

▲ iainmerrick 4 days ago | parent [-]

It works the way you want if you add a trailing comma:

  important_numbers = {
    "x": 3,
    "y": 42,  # Answer to the Ultimate Question!
    "z": 2,
  }

You might complain that that seems a bit obscure, but it only took me 10 or 20 seconds to discover it after pasting the original code snippet into an editor.

The trailing comma is an improvement as it makes the diff clearer on future edits.

Edit to add: occurs to me that I oversimplified my position earlier and it probably looks like I'm trying to have it both ways. I do advocate aiming for clean and clear formatting; I'm just against doing this manually. You should instead use automation, and steer it lightly only when you have to.

For example, I explicitly don't want people to manually "tab-align" columns in their code. It looks nice, sure, but it'll inevitably get messed up in future edits. Better to do something simpler and more robust.

▲ maratc 4 days ago | parent [-]

The trailing comma communicates an intent of possibly adding more things in the future. I actually use it quite a lot -- when I have that intent.

In the above example, if I think I have listed all of the `important_numbers`, there is a certain point of not having the trailing comma there.

Here's another terrible example from `black`:

From this:

    my_print(f"This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}", 
        a=1, b=2)

To this:

    my_print(
        f"This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}",
        a=1,
        b=2,
    )

The trailing comma it added makes no sense whatsoever because I can not have an intent of adding more things -- I've already exhausted the parameters in the string!

On the top of it, I don't quite get why I need to change the way I write in order to please the machine. Who should be serving whom?

Edit: changed "print" to "my_print" to not have to argue about named parameters of print ("sep", "file" etc.).

Edit 2: here's a variant that `black` has no issues with whatsoever. It does not suggest a trailing comma or any other change:

    my_print(f"This string has two params, `a` which is {a} and `b` which is {b}", a=1, b=2)

So an existence of a trailing comma is a product of string length?

▲ lenzm 3 days ago | parent [-]

Yes, it gets a trailing comma if it's on it's own line. That way when you add/remove arguments in a multi-line call it's only a one-line diff. This doesn't apply when the diff is only one line anyway.

Who's to say you don't add a new argument to the function in the future, like

    my_print(
        "This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}",
        a=1,
        b=2,
        color_negative_red=True,
    )

▲ maratc 3 days ago | parent [-]

> it gets a trailing comma if it's on it's own line.

Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/etc. Who's to say I won't add this in the future:

    my_print("a={a}, b={b}", a=1, b=2, color_negative_red=True)

So do I need to have this now?

    my_print("a={a}, b={b}", a=1, b=2,)

There's a very responsive playground at https://black.vercel.app/ and whatever it does looks strange to me, because the underlying assumptions look inconsistent one with the other (to my eye at least.) Specifically, "the length of the string should decide whether there is a trailing comma or there isn't" makes zero sense.

▲ thfuran 3 days ago | parent [-]

>Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/et

No, the argument is quite specifically that a one line diff to add a new argument/element to the end of a list is preferable to a two line diff to do the same thing. The presence of the trailing comma is necessary to achieve that only when elements are on their own line.

▲ maratc 3 days ago | parent [-]

Ok, we're then back to `print` example:

    print(
        'Hello there from a very long line abcdefghijklmnopqrstuvwxyz',
        sep=' ', 
        end='\n', 
        file=None, 
        flush=False,
    )

All of the existing named parameters to `print()` function are already provided, and that standard function is highly unlikely to change. Should I add another string to `print`, I will have to do it before the named parameters anyway. There is no sense in the trailing comma here however you look at it.

Edit: sorry for using single quotes, in my 20 years of writing Python it was never an issue, but now with `black` it apparently is.

	▲	iainmerrick 3 days ago \| parent [-]
		I think this boils it down to the essence. Whether you use a trailing comma here, and whether you use single or double quotes, is just bike-shedding. If there's an automated tool that can make a consistent choice everywhere, that's worthwhile.

▲ Revisional_Sin 3 days ago | parent | prev [-]

Putting a trailing comma stops that.

	▲	maratc 3 days ago \| parent [-]
		https://news.ycombinator.com/item?id=45169331

▲ raincole 4 days ago | parent | prev [-]

People like you are the exact reason why linter is a thing.

▲

forrestthewoods 4 days ago | parent [-]

Don’t be rude.

I write perfectly legible code. More legible than a linter infact. Because the rules for what is ideal are not so simple as to be encoded in simple lint rules. Sure it gets like 95%. But the last 5% is so bad it ruins the positives.

If your goal is “code that is easy to read and understand” then a linter is only maybe the first 20%. Lots of well linted code is thoroughly inscrutable.

	▲	raincole 4 days ago \| parent \| next [-]
		> I write perfectly legible code I 100% believe you. And for god's sake please use linter. British and American spelling are both 100% legible English. But when multiple people coauthor a book, they should stick to one instead of letting each author use their favorite spelling.
	▲	stavros 4 days ago \| parent \| prev \| next [-]
		I disagree. It gets you 95%, and do you know how many people are better than that? One in twenty. I'll gladly pay the price of making the one person's code worse if it improves the other nineteen's.
	▲	genericspammer 4 days ago \| parent \| prev [-]
		Im sure you write very readable code, but in most companies, there are a bunch of devs who completely rape the codebase with unintelligble bullshit. The linter is the first line of defense against these bozos, unfortunately it must be enforced company wide.