Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Formatting code should be unnecessary

maxleiter.com

Post reply on HN
Print view View original

261–270 of 484 posts

Re: Formatting code should be unnecessary

#261

Post by maest »

rapind wrote: post #256
socalgal2 wrote: post #152

Earlier quoted context omitted.

some settings have advantages. For example, trailing commas on tables [ 'apple', 'banana', 'orange', ] has an advantage over [ 'apple', 'banana', 'orange' ] Because adding a new line at the end of the table (1) requires editing 1 line, instead of 2 (2) makes the diffs in code review smaller and easier to read and review. So a bad choice makes my life harder. The same applies to local variable declarations. Sorted lis…

Let this sink in though: [ 'apple' , 'banana' , 'orange' ]

That makes prepending an element a special case.

Re: Formatting code should be unnecessary

#262

Post by IshKebab »

3036e4 wrote: post #101
anticodon wrote: post #57

Earlier quoted context omitted.

Yes. In Python, black formatter consistently breaks SQLAlchemy queries in an unreadable way (e.g. splitting conditions over multiple lines when it's not really necessary and makes reading harder).

For C++ clang-format does things like that all the time as well. Of course it has no idea what semantically belongs together on the same line or not. I wish the C++ world had settled on some other standard linter.

clang-format is probably the worst of the autoformatters. They tried to get fancy with a sort of global optimisation algorithm but in practice it's buggier and uglier than the classic Prettier algorithm which is elegant and generally works very well. It's also way less diff friendly.

I wouldn't draw any conclusions about autoformatters from clang-format.

Re: Formatting code should be unnecessary

#263

Post by layer8 »

saagarjha wrote: post #253
layer8 wrote: post #222

Earlier quoted context omitted.

100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for…

This makes it really annoying to grep for log messages. I can't control what you do in your codebase but I will always argue against this the ones I work on.

I haven’t found this to be a problem in practice. You generally can’t grep for the complete message anyway due to inserted arguments. Picking a distinctive formulation from the log message virtually always does the trick. I do take care to not place line breaks in the middle of a semantic unit if possible.

Re: Formatting code should be unnecessary

#264

Post by IshKebab »

numtel wrote: post #193

With how much LLMs do nowadays, I'm waiting for the time when specifying types is unnecessary. Like, it if can write code, shouldn't we also be able to have an AI type checker?

Systematic checking like that is pretty much LLM's worst case. They're really bad at it. Definitely better to use them to suggest types.

Re: Formatting code should be unnecessary

#265

Post by saagarjha »

layer8 wrote: post #263
saagarjha wrote: post #253

Earlier quoted context omitted.

This makes it really annoying to grep for log messages. I can't control what you do in your codebase but I will always argue against this the ones I work on.

I haven’t found this to be a problem in practice. You generally can’t grep for the complete message anyway due to inserted arguments. Picking a distinctive formulation from the log message virtually always does the trick. I do take care to not place line breaks in the middle of a semantic unit if possible.

Yes, I find the part of the message that doesn't have interpolated arguments in it. The problem is that the literal part of the string might be broken up across lines.

Re: Formatting code should be unnecessary

#266

Post by balamatom »

delusional wrote: post #227
account42 wrote: post #167

Earlier quoted context omitted.

So fix your setup? Why should others with wider screens leave space on their screen empty for your sake? Especially 80 characters is a ridiculously low limit that encourages people to name their variables and functions some abbreviated shit like mbstowcs instead of something more descriptive.

> So fix your setup? Why should others with wider screens leave space on their screen empty for your sake? What a terrible attitude to have when working with other people. "Oh, I'm the only one who writes Python? Fix your setup. why should I, who know python, not write it for your sake?" "Oh, I'm the only one who speaks German? Fix your setup. Why should I, who know German, not speak it for your sake?" How about doin…

What do you do about the "oh, I'm the only one who cares about [???]? should I just fucking kill myself then?" Many such cases.

>How about doing it because your colleagues, who you presumably like collaborating with to reach a goal, asks you to?

If a someone wants me to do a certain thing in a certain way, they simply have to state it in terms of:

- some benefit they want to achieve

- some drawback they want to avoid

- as little as an acknowledged unexamined preference like "hey I personally feel more comfortable with approach X, how bout we try that instead"

I'm happy to learn from their perspective, and gladly go out of my way to accomodate them. Sometimes even against my better judgment, but hell, I still prefer to err on the side of being considerate. Just like you say, I like to work with people in terms of a shared goal, and just like you do, in every scenario I prefer to assume that's what's going on.

If, however, someone insists on certain approaches while never going deeper in their explanations than arbitrary non-falsifiable qualifiers such as "best practice", "modern", "clean", etc., then I know they haven't actually examined those choices that they now insist others should comply with. They're just parroting whatever version they imagine of industry-wide consensus describes their accidental comfort zone. And then boy do they hate my "make your setup assume less! it's the only way to be sure!". But no, I ain't reifying their meme instead of what I've seen work with my own two.

Re: Formatting code should be unnecessary

#267

Post by DonHopkins »

einpoklum wrote: post #165
automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

If you ride a bike every day, bike sheds are rather important. If you write and edit and read and search code every day, code formatting is rather important.

You're missing what the bike shedding metaphor is about. It's not about having bike sheds or not, it's about coloring bike sheds, which every day bike riders in their right mind really don't give a shit about, because it doesn't affect their life in any tangible way.

Re: Formatting code should be unnecessary

#268

Post by iainmerrick »

maratc wrote: post #250
forrestthewoods wrote: post #61

Earlier quoted context omitted.

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 fee…

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.

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.

Re: Formatting code should be unnecessary

#269

Post by IshKebab »

Jean-Papoulos wrote: post #128

So I need to run a tool to even be able to read the code. No thank you, if anything goes wrong your file is now garbage.

Doesn't seem like a real risk - these files are all version controlled.

The bigger problem is you now need custom tooling for your IDE, version control, diff & merge, code review, code hosting, etc. etc.

Re: Formatting code should be unnecessary

#270

Post by pasc1878 »

eviks wrote: post #58
kelseyfrog wrote: post #2

The tradeoff here is not being able to use a universal set of tooling to interact with source files. Anything but text makes grep, diff, sed, and version control less effective. You end up locked into specialized tools, formats, or IDE extensions, while the Unix philosophy thrives on composability with plain text. There's a scissor that cuts through the formatting debate: If initial space width was configurable in th…

> If initial space width was configurable in their editor of choice, would those who prefer tabs have any other arguments? Yes, of course, because tab width is * dynamically* flexible, so initial space width isn't enough

Yes because if you want to deindent with tabs it is just delete one character whilst spaces requires you top delete x characters where x is the number of spaces you indent by.
Post reply on HN