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

161–170 of 484 posts

Re: Formatting code should be unnecessary

#161

Post by psychoslave »

danielheath wrote: post #55
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 you’re going to store the source in a canonical format and unpack that to suit each developer… why should the canonical format just be regular source code? All the same tools can exist with a text backend, and you get grep/sed support for free too!

That’s seems like a genious remark actually. If you store the abstract objects and have the mechanism to transform to whatever the desired output form is, it’s almost trivial to expose a version as files and text rendering for tools that are thus oriented, isn’t it?

Re: Formatting code should be unnecessary

#162

Post by shit_game »

chowells wrote: post #86

I have to disagree with the premise. Formatting code is a critical communication channel. Well-formatted code should tell you: 1. The developer has enough experience to understand that formatting matters. 2. The developer has enough discipline to stick with their chosen formatting rules. 3. The developer has the taste necessary to choose good formatting rules. 4. The developer has the judgement necessary to identify…

Would you say that someones code formatting is a shibboleth? How do you feel about formatters and linters in regards to this?

Re: Formatting code should be unnecessary

#163

Post by Marazan »

someothherguyy wrote: post #143
elevation wrote: post #88

Earlier quoted context omitted.

Formatters eliminating long lines is a pet peeve of mine. About once every other project, some portion of the source benefits from source code being arranged in a tabular format. Long lines which are juxtaposed help make dissimilar values stand out. The following table is not unlike code I have written: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_co…

setup_spi( &adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01 ); setup_spi( &eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02 ); setup_spi( &mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08 ); ftfy

That is harder to read than the long line version.

However, it is the formatting I adopt when forced to bow down to line length formatters.

Re: Formatting code should be unnecessary

#164

Post by tsimionescu »

jupp0r wrote: post #56
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.

I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

I am at the opposite end. Having any line length constraints whatsoever seems like a massive waste of time every time I've seen it. Let the lines be as long as I need them, and accept that your colleagues will not be idiots. A guideline for newer colleagues is great, but auto-formatters messing with line lengths is a source of significant annoyance.

Re: Formatting code should be unnecessary

#165

Post by einpoklum »

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.

Re: Formatting code should be unnecessary

#166

Post by mr_mitm »

HelloNurse wrote: post #159
torginus wrote: post #153

Earlier quoted context omitted.

The problem is that tools like ESlint often come with highly opinionated rules that might not even be applicable all of the time (leading to me having to manually turn them off via annotations) And there's no centralized idea on best practices.

And best practices depend. Recently, I discovered that the ruff linter for Python doesn't like the assert statement, because since it does nothing in "optimized" mode it isn't reliable. But such complaints about unit tests are not particularly useful.

Rule S101 [1] is not in the default settings. If you choose to enable it, you have the possibility of disabling it for your tests like so:

    [tool.ruff.lint.per-file-ignores]
    "tests/*" = ["S101"]
(Besides, this was about formatting, not linting, but I realize it's related.)

[1] https://docs.astral.sh/ruff/rules/

Re: Formatting code should be unnecessary

#167

Post by account42 »

komali2 wrote: post #119
elevation wrote: post #88

Earlier quoted context omitted.

Formatters eliminating long lines is a pet peeve of mine. About once every other project, some portion of the source benefits from source code being arranged in a tabular format. Long lines which are juxtaposed help make dissimilar values stand out. The following table is not unlike code I have written: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_co…

Devs have different pixel count screens. Your table wrapped for me. The short line equivalent looks best on my screen. Thus 80 or perhaps 120 char line lengths!

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.

Re: Formatting code should be unnecessary

#168

Post by account42 »

elevation wrote: post #88
jupp0r wrote: post #56

Earlier quoted context omitted.

I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

Formatters eliminating long lines is a pet peeve of mine. About once every other project, some portion of the source benefits from source code being arranged in a tabular format. Long lines which are juxtaposed help make dissimilar values stand out. The following table is not unlike code I have written: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_co…

Another issue with fixed line lengths is that it requires tab stops to have a defined width instead of everyone being able to choose their desired indentation level in their editor config.

Re: Formatting code should be unnecessary

#169

Post by falcor84 »

chowells wrote: post #86

I have to disagree with the premise. Formatting code is a critical communication channel. Well-formatted code should tell you: 1. The developer has enough experience to understand that formatting matters. 2. The developer has enough discipline to stick with their chosen formatting rules. 3. The developer has the taste necessary to choose good formatting rules. 4. The developer has the judgement necessary to identify…

The same personality attributes can be assessed even better based on penmanship, so going forward, I'll require all PRs to be submitted in cursive

Re: Formatting code should be unnecessary

#170

Post by raincole »

forrestthewoods wrote: post #108
raincole wrote: post #77

Earlier quoted context omitted.

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

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.

> 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.

Post reply on HN