Hacker News new | past | comments | ask | show | jobs | submit login

I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it.

Having a standard is more important than the standard being excellent.




> Having a standard is more important...

Let me take a shot at why it's important.

We spend years peering at code hunting for tiny, miniscule mistakes. Thus we're training ourselves, quite rigorously, to spot minor deviations.

We're also irrational in the moment: our aesthetic sense is bothered by certain patterns, and our social sense wants to assign blame for this "wrongness" to individuals.

An auto-formatter removes a ton of deviations that don't matter, and desocializes the aesthetics.

This saves code reviewers time and stress and helps them focus on what actually matters in the code.

And it only has to save more time than it takes to run "pipenv run black" to be measurably worth it.


Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.



I've been meaning to update that post to mention that Poetry has been releasing fixes and improvements more frequently than Pipenv. Poetry is great for developing packages, too.

(Showing up in an HN thread is a neat little milestone for my blog and me. Thanks for sharing!)


I use poetry. It has bugs (`poetry install/add/update` treats git-URL dev-dependencies as end-user dependencies). I sent a bug fix and it was not merged for months. I now use my own fork of Poetry with this fix added.


I used pipenv on a few projects and my experience has been somewhere between "this is hot garbage" and "meh".

I'm no longer using it for Python projects.


I've previously profiled pipenv and found it to be slowed down massively due to launching pip for each package it was working on. Unfortunately the maintainers think the progress bar is more important than performance: https://github.com/pypa/pipenv/issues/2207


That's interesting; they actually discuss the issue and talk about parallelizing it, but all you need to do is pass a requirements file to pip.

It would be nice if pip could act more as a base tool and pass information back to a wrapper.


I'm coming from managing virtualenvs with s*ty bash scripts on a complex application, so pipenv got rid of a ton of jank, even though it's slow and has issues resolving certain dependencies.

I like it because I can document most maintenance tasks as "pipenv sync && pipenv run X" and they Just Work with exactly the library versions specified for that commit.

But definitely look into poetry if you're packaging a library.


Thanks for the suggestion!


It's not you. There are plenty of people who dislike pipenv. Another commentor suggested poetry, which is what I favor when 'python3 -m venv .env' isn't appropriate.


I have similar experience, pipenv is not bad but it's definitely not great. Personally I'm starting to use poetry in new projects and it's being great, much better than pipenv.

Whenever I have time I want to migrate all my pipenv projects to poetry.


> It's so slow so often, and I can't understand why.

The Python community is victim to pipenv's creator's marketing and shoehorning, that's why.


Probably because pipenv is the worst Python package manager ever.


I'm saving your and cjbprime's comments for future reference. You've both perfectly expressed the benefit and contextual benefit of code formatters.


> no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code

It always strikes me as strange that we spend our own effort and time on systems that mandate code style when my unambiguously correct style and my coworkers obviously incorrect style both end up converted to the same AST for any useful work. Why isn't style an entirely local choice, with a higher-level representation of the code stored canonically?

Better question: What wheel did I point towards and suggest be reinvented?


JetBrains' MPS does exactly that - it stores the code as an AST, then renders it based on your own preferences:

https://www.jetbrains.com/mps/concepts/


Seems like the underlying format is unrelated to editing with customizable AST—in fact, that seems like it'd make things like code review pretty miserable. You'd have to upgrade all tooling to be ast-aware.

That said, once upgraded, that would be far, far, far superior to text. Our tooling hit the limits of text a long time ago: consider how terrible diffs are at communicating simple operations like indentation changes, or how basic our refactoring is even in the best case scenarios.


Wow this is a killer feature. If you're really zealous about how things "ought to be", now you can just write your preferences out once and be done with it. Stinks that it locks you into JetBrains, presumably: unless, is this part open-sourced?


> What wheel did I point towards and suggest be reinvented?

Pretty printing.


One term for this, I believe, is “structural editors.”


Actually, the term is “structure editor”:

https://en.wikipedia.org/wiki/Structure_editor


I'm not looking for an "excellent" standard. I'm looking for something that isn't a complete outlier.

I feel like in every one of these formatter discussions people are waiting to pounce on anyone who takes issue with the formatting. I'm totally down with formatting: prettier, dart_style, rustfmt, gofmt, uncrustify, I use and love them all both professionally and personally (well, gofmt is bad at wrapping but the language is bad at wrapping in general). But in all these cases, these tools are either configurable or they set a standard for how to format code for $lang. Black does neither, which is fine, but its options then are "pick a common convention" or "pick an uncommon convention". All I'm saying is that I wish it had done the former.


I don't universally love what autoformatters do to code my coworkers wrote. I've worked with plenty of people who manage to do fewer weird formatting things than what mediocre autoformatters do.


My sense is that configurable autoformatters are doomed to suck.

Because an autoformatter with 10 simple yes/no options has 1024 different ways those options can interact, and an autoformatter with 20 yes/no options has 1,048,576 different ways that they can interact. It's simply not possible to make sure that you're going to get reliably good results in the face of that kind of combinatorial explosion.

Versus, if there's only one way that it will format things, then the people designing the rules have a single stationary target that they can aim at.


This isn't really the case, though. Lots of options are completely orthogonal (e.g. tabs vs spaces and function brace style don't really affect each other). My experience with clang-format has been that each option (mostly) only affects a single token type, which is determined using clang as a backend. I've only seen satisfactory results.

If you don't have as powerful a backend as the full clang paraer/lexer on the other hand, I could quickly see things breaking as you described.


Let me introduce you to Uncrustify (well, its GUI anyway) [1]. It's ridiculously configurable and super good at what it does.

[1]: http://universalindent.sourceforge.net/screenshots.php


> I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it.

I'm completely indifferent to autoformatters turning my coworkers' code from one perfectly readable format into another. The "problem" they solve is a ridiculous thing to worry about. Having a standard is not important, it's petty.

What I do dislike is having to fight the autoformatter because for some reason some teams use different settings. I dislike autoformatters turning code into something that is objectively harder to read -- sometimes it's not a matter of taste. Even when they work, I dislike even a second on something that only satisfies other peoples' pettiness. I also dislike git blame being useless because someone reformatted all the code for no good reason.


> Having a standard is more important than the standard being excellent.

Neither is very important, though. It's just formatting and your code will run the same regardless.


They're not very important if you're the only developer on your team.

If you're working with others, though, then it becomes very important. I don't think I'm being entirely hyperbolic when I say that inconsistent or poorly-chosen formatting rules are the death of 1,000 cuts for a team's productivity.

There's a tiny but existent cost that's incurred every time formatting rules that aren't diff-stable result in a noisy code review that takes longer to read, or makes it harder for reviewers to discern the real changes from the formatting junk. There's a tiny but existent cost when excess delta makes it harder to gitblame. There's a tiny but existent cost when people have to stop and think about how to format their code manually. Or when they have to stop and debate formatting. Or when they read someone else's code slightly more slowly because different formatting rules make it harder for them to skim it or rely on pattern recognition instead of careful reading to understand its structure.

All those tiny little costs add up to something that's not so tiny. And it's so easy to make it just disappear, for the low low cost of swallowing one's pride, by simply adopting an opinionated autoformatter.


> There's a tiny but existent cost that's incurred every time formatting rules that aren't diff-stable result in a noisy code review that takes longer to read, or makes it harder for reviewers to discern the real changes from the formatting junk. There's a tiny but existent cost when excess delta makes it harder to gitblame.

Don't reformat code you didn't otherwise touch. That's just common sense. Common sense autoformatters lack.

> There's a tiny but existent cost when people have to stop and think about how to format their code manually.

I rarely think about how I format my code. When I do, it's because the code is hard to format in a readable way, in which case an autoformatter will produce garbage.

> Or when they have to stop and debate formatting.

"Doctor, it hurts when I do this."

> Or when they read someone else's code slightly more slowly because different formatting rules make it harder for them to skim it or rely on pattern recognition instead of careful reading to understand its structure.

Neglible. To the contrary, different formatting reminds you that you did not write this code and you should read it more carefully because you can't expect its creator to think the way you do.


A kindred spirit.

I've never been able to wrap my head around people having strong opinions on style issues. I'll defer to whoever cares the most on the team and then just do that. When I look at the problems in code bases, rarely has "slightly inconsistent formatting" been at the top of the list.


You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.


Why use many word when few word do trick


Because you don't know if they've done the trick. That's why natural language is padded with extra words to add context and help rule out misunderstandings. The grammatical rules of agreement are one mechanism to do this.

And you can see the phenomenon of over-abbreviation by reading a few debates on twitter and repeatedly seeing, "how can you not understand what I tweeted?!"


FYI you're replying to a joke from The Office (US) https://www.youtube.com/watch?v=_K-L9uhsBLM


No, that's a completely invalid objection. Punctuation in natural languages isn't just aesthetic, it changes meaning.


Punctuation, or lack of it, can change the meaning in programming languages too.

https://medium.freecodecamp.org/codebyte-why-are-explicit-se...


Yeah, but no one would remove punctuation from a program because they think it looks nicer.

> Javascript developers

Oh, of course.


I remove semicolons from JS b/c I feel like they are a bit of a hack. Except where it's required by the language (for loops, which are becoming less used quite rapidly), your code generally shouldn't be so complex as to require semicolons for readability.

Having said that, I've been introducing a lot more colons, since I use TypeScript.


I was referring to punctuation that is, in some way, actually necessary. No one ends their lines with semicolons in python although it's valid. The rules when the interpreter will "insert" them are obvious. Not so in Javascript.


Don't forget gofmt.


That's a mostly invalid counter-objection. Technically true, but with context its usually recoverable.


That and it also saves our fingers' lives. Seriously, formatting code "by hand" just hurts. I highestly recommend anyone concerned about developing rsi to start autoformatting their code.


Why not let every user apply their own formatter? I bet that with a little work in the toolchain (git, editors, less), you can make this work.


Mostly because it's impossible to autoformat code well. You can only just barely get to "good enough".


In theory yes, but the grandparent just gave an example of where they don't like what it did to code. Could easily be someone else's.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: