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

111–120 of 484 posts

Re: Formatting code should be unnecessary

#111

Post by hnlmorg »

michaelmrose wrote: post #60
pwdisswordfishz wrote: post #46

Earlier quoted context omitted.

That's why you grep for a syntactic structure, not undifferentiated text.

Which grep doesn't do and you need to either use a new different tool or more likely several for little real benefit

grep is half a century old now.

If we can’t progress our ecosystem because we are reliant on one very specific 50+ year old line parser, then that says more about the inflexibility of the industry to move forward than it does about the “new” ideas being presented.

Re: Formatting code should be unnecessary

#112

Post by swiftcoder »

wartijn_ wrote: post #98
garbagepatch wrote: post #76

Earlier quoted context omitted.

> just make a choice Now you are bikeshedding. Just go with the defaults.

Which defaults? The programming languages I’ve worked with don’t have defaults for everything related to formatting. Editor defaults don’t work, since not everybody uses the same editor. So you have to make a choice somewhere.

A lot of (relatively) recent languages do have defaults. Go and rust both come with an auto formatter out of the box, and defaults that are sane enough to just run with

Re: Formatting code should be unnecessary

#113

Post by forrestthewoods »

setopt wrote: post #82
forrestthewoods wrote: post #62

Earlier quoted context omitted.

Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate more than a stupid linter turning a sprinkling of logs into 7 line monsters. cargo fmt is especially bad about this. It’s so bad.

It’s tricky to find an objective optimum. Personally I’ve been happy with up to 100 chars per line (aim for 80 but some lines are just more readable without wrapping). But someone will always have to either scroll horizontally or wrap the text. I’m speaking as someone who often views code on my phone, with a ~40 characters wide screen. In typography, it’s well accepted that an average of ~66 chars per line increases…

I don’t think code is comparable. Reading code is far more stochastic than reading a novel.

For C/C++ headers I absolutely despise verbose doxygen bullshit commented a spreading relatively straightforward functions across 10 lines of comments and args.

I want to be able to quickly skim function names and then read arguments only if deemed relevant. I don’t want to read every single word.

Re: Formatting code should be unnecessary

#114

Post by rho4 »

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…

Not caring about formatting also signals to me that:

- they have probably never worked on a codebase where files are edited by more than 1 person

- they have never done any significant amount of merging between branches

- they have never maintained a large codebase

- they have never had to refactor a large codebase

- they don't use diff/comparison tools to read the history of their codebase

- they have never written any tooling for their codebase

- they are not good team-players and/or only care about their own stuff

Re: Formatting code should be unnecessary

#115

Post by babel_ »

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 blog entry is short and simple, perhaps consider reading it before knee-jerk reacting to the title, and then you might understand why "should" and "unnecessary" are operative in said title.

Re: Formatting code should be unnecessary

#116

Post by wonger_ »

__MatrixMan__ wrote: post #42

Unison doesn't move the formatting choices further than the machine on which the code was written. The codebase only contains the AST. Its such a cool idea, though I haven't spent much time using it in anger, so its hard to say if its a useful idea.

Yeah, if any language has potential for AST source of truth instead of textual source of truth, it's Unison.

I'm just waiting for a breakthrough project to show that it's ready for wider adoption. Leaving text-based tooling is a big ask.

The principles behind Unison, for those who haven't read them yet: https://www.unison-lang.org/docs/the-big-idea/#richer-codeba...

> Each Unison definition is identified by a hash of its syntax tree.

Re: Formatting code should be unnecessary

#117

Post by a_e_k »

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…

Yes, so much this!

I've often wished that formatters had some threshold for similarity between adjacent lines. If some X% of the characters on the line match the character right above, then it might be tabular and it could do something to maintain the tabular layout.

Bonus points for it's able to do something like diff the adjacent lines to detect table-like layouts and figure out if something nudged a field or two out of alignment and then insert spaces to fix the table layout.

Re: Formatting code should be unnecessary

#119

Post by komali2 »

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…

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!

Re: Formatting code should be unnecessary

#120

Post by _ZeD_ »

good luck with that.. I didn't had a decent IDE capable of even implementing elastic tab stops... I expect people using hex editors to flip bytes directly on the binary blob saved on disk instead of using the appropriate tools to view the "source" files.

btw: have a look at how much disdain was reserved for systemd and its pletora of binary blobs + custom tools (e.g. the journal stuff) ... and that was basically forced upon from the distributions

Post reply on HN