Earlier quoted context omitted.
Thats a slippery slope towards storing semantics and displaying locally preferred syntax ;)
And the bikeshedding has begun...
What's the nuclear reactor in this analogy?
Formatting code should be unnecessary
151–160 of 484 posts
Re: Formatting code should be unnecessary
#152I'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.
some settings have advantages. For example, trailing commas on tables
[
'apple',
'banana',
'orange',
]
[
'apple',
'banana',
'orange'
]
Sorted lists (or sorted includes) is also something that makes my life easier. If they're not sorted then everyone adds their new things to the end, which means there are many times more merge conflicts. sorted doesn't mean there are zero but does mean there are less than "append to the end". So, just like an auto-formatter is there to save time, don't waste my time by not sorting where possible.
Also, my OCD hates inconsistency. So
[1, 2, 3]
{a, b, c}
[ 1, 2, 3 ]
[ a, b, c ]
[1, 2, 3]
{ a, b, c }
Re: Formatting code should be unnecessary
#153I'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.
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.
Re: Formatting code should be unnecessary
#154Formatting code is a typical bikeshed argument. Nobody can say a thing about the nuclear reactor, everyone has an opinion about the bike-shed.
Re: Formatting code should be unnecessary
#155I'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.
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.
eslint is slow and has terrible UX. Use Biome instead.
Re: Formatting code should be unnecessary
#156Re: Formatting code should be unnecessary
#157Earlier 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…
People have already outlined all the reasons why the long line might be less than optimal, but I will note that really you are using formatting to do styling.
In a post-modern editor (by which I mean any modern editor that takes this kind of thing into consideration which I don't think any do yet) it should be possible for the editor to determine similarity between lines and achieve a tabular layout, perhaps also with styling for dissimilar values in cases where the table has a higher degree of similarity than the one above. Perhaps also with collapsing of tables with some indicator that what is collapsed is not just a sub-tree but a table.
Re: Formatting code should be unnecessary
#158The 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…
What if the common intermediate encoding is text, not binary? Then grep/diff/sed all still work. If we had a formatting tool that operated solely on AST, checked in code could be in a canonical form for a given AST. Editors could then parse the AST and display the source with a different formatting of the users choice, and convert to canonical form when writing the file to disk.
All mainstream editors that agree to work on a standard AST for any given language could be nice. I'm not expecting that to happen at any time in future.
About grep and diff working on a textual representation of the AST, it would be like grepping on Javascript source code when the actual source code is Typescript or some other more distant language that compiles to Javascript (does anybody remember Coffescript?) We want to see only the source code we typed in.
By the way, add git diff to the list of tools that should work on the AST but show us the real source code.
Re: Formatting code should be unnecessary
#159I'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.
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.
Re: Formatting code should be unnecessary
#160In most languages (other than e.g. Python), formatting code is actually unnecessary...