Earlier quoted context omitted.
The second two lines of your example smell like LoD violations. It's not a formatting problem, it's a structural problem.
Sometimes you have to use libraries that are badly designed.
Formatting code should be unnecessary
191–200 of 484 posts
Re: Formatting code should be unnecessary
#192Earlier 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.
I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.
Re: Formatting code should be unnecessary
#193Re: Formatting code should be unnecessary
#194Re: Formatting code should be unnecessary
#195I wrote an article saturday on visual programming which is very related to this, but my thinking is the opposite of this article. Raw text is amazing at smaller scales. The ability to apply a bunch of intermediate incorrect transformations to reach a valid destination is invaluable (like doing a bunch of hacky find/replace). Projectional editors like JetBrains MPS have tons of disadvantages vs text, and the few advan…
Re: Formatting code should be unnecessary
#196Earlier quoted context omitted.
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
#197With 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?
To have something that sometimes checks the types and some times does is not a feasible solution.
Re: Formatting code should be unnecessary
#198Some (sometimes) desirable source code formatting cannot be deduced from the abstract syntax tree alone: Consider the following (pseudo-)code example: bar.glob = 1; bar.plu.a1 = 21; bar.plu.coza = fol; Should this code formatted this way? Or should it be formatted bar.glob = 1; bar.plu.a1 = 21; bar.plu.coza = fol; to emphasize that three assignments are done? Or should this code be formatted bar.glob = 1; bar.plu .a1…
Re: Formatting code should be unnecessary
#199Earlier quoted context omitted.
Printing industry have not been anything close to forever, even writing is relatively novel compared to human spoken languages. All that said, I'm interested with this 132 number, where does it come from?
Printers aside the VT220 terminal from DEC had a 132 column mode. Probably it was aping a standard printer column count. Most of the time we used the 80 column mode as it was far more readable on what was quite a small screen.
Interesting here perhaps is that even back then it was recognized, that for different situations, different display modes were of advantage.
Re: Formatting code should be unnecessary
#200I'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.