Live data from Hacker News

Formatting code should be unnecessary

maxleiter.com

321–330 of 484 posts

Re: Formatting code should be unnecessary

#321
post #312
post #105

Earlier quoted context omitted.

> I've never understood why we still look at the plain text representation of code, and not a visualization of the code that makes more sense. I suppose this is because nobody has been able to create good tooling for it (the visualization itself, the efficient editing, etc). You'll have to deal with the text version of it at some point if not all tools that we rely on get a version for the new visualization. Another…

Um isn't that what Lisp and its children / siblings have been all about. I've written a bit of Closure it has a very clear idea that code is data and data is code. Your code is trivially serializable in your mind and by various tools, and because it is lisp - it all kinda makes sense. I really wish we lived in a universe where a lisp became the lengua franca of the world instead of javascript, as almost happened with…

The "code is data" aspect of lisp seems orthogonal to how code is still written as text, and btw lisp is still written using text. You still need to indent all these parentheses.

Virtually all programming languages are parsed into ASTs, and these ASTs can be serialized back. This is what formatters/"prettifiers" usually do.

Did I miss something?

Re: Formatting code should be unnecessary

#322
post #39

Earlier quoted context omitted.

> The entire OS was built around these source files. And how did that work out for them? This seems like one of the many cases where unix won out by being a lowest common denominator. Every platform can handle plain text.

> This seems like one of the many cases where unix won out by being a lowest common denominator. The lowest common denominator rather is binary blobs. :-)

The conversion of which to text and back has historically proven rather fraught.

Re: Formatting code should be unnecessary

#323

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…

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.

I think you have that backward. Allowing everyone to choose their desired indentation in their editor config is the issue. That's insane!

Re: Formatting code should be unnecessary

#324

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 went through this on a few projects, and what surprised me the most was that some devs have very strong opinions about import ordering. I mostly rely on the IDE to manage imports, and most the time they're not even visible. We had to add a lot of prettier rules to get import orders just right.

Re: Formatting code should be unnecessary

#325
post #241

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.

> Why should others with wider screens leave space on their screen empty for your sake? Because "I" might be older or sight-impaired, and have "my" font at size 32, and it actually fills "my" (wider than yours) screen completely? Would you advise me to "fix my eyes" too? I'd love to! "Why should I accommodate others" is a terrible take.

I would advise you to buy one of these: https://www.dell.com/en-ca/shop/dell-ultrasharp-49-curved-us...

80-column line lengths is a pretty severe ask.

Re: Formatting code should be unnecessary

#327

Earlier quoted context omitted.

> I've never understood why people care so much about the linter settings. Source code formatting programs are not the same as lint[0] programs. The former rewrites source code files such that the output is conformant with a set of layout rules without altering existing logic. The latter is a category of idempotent source code analysis programs typically used to identify potential implementation errors within otherwi…

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

> This is most noticeable in open source contributions. Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool.

This wouldn't happen nearly as much if you had a defined set of formatting rules plugged into CI instead of chaos

Re: Formatting code should be unnecessary

#328

Earlier quoted context omitted.

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

> 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" You're moving the goalposts of this discussion. The guy I was responding to said "fix your setup" to another person saying "Your table wrapped for me. The short line equivalent looks best on my screen." That's a stated preference based…

"Best practice" type arguments are the universal excuse for remaining inconsiderate of the fact that different people interact with code differently, but fair enough I guess

Re: Formatting code should be unnecessary

#329
post #275

Earlier quoted context omitted.

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…

I may be unusual in a way I treat my profession and care about my professional output (the code I write), and I take both very seriously. There's a quote from Steve Jobs (or maybe his carpenter father): “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going…

I don't think we'll ever fully agree, but I'd just like to clarify that I value that kind of craftsmanship too!

I just honestly believe that if you fully automate the formatting, the results are better than if you do it painstakingly by hand; better by virtue of being more consistent. It's using the right tool for the job.

Re: Formatting code should be unnecessary

#330
post #276

Earlier quoted context omitted.

I’d also add: * [Difftastic]( https://difftastic.wilfred.me.uk/ ) — my go-to diff tool for years * [Nu shell]( https://www.nushell.sh/ ) — a promising idea, but still lacking in design/implementation maturity What I’d really like to see is a *viable projectional editor* and a broader shift from text-centric to data-centric tools. The issue is that nearly everything we use today (editors, IDEs, coreutils) is built aro…

But almost every editor worth its salt these days has structural editing. https://docs.helix-editor.com/syntax-aware-motions.html https://www.masteringemacs.org/article/combobulate-structure... https://zed.dev/blog/syntax-aware-editing Etc etc.

And that's a great thing! I look forward to them being more mature and more widely adopted, as I have tried both zed and helix, and for the day to day work they are not yet there. For stuff to take traction though. Both of them, however, don't intend to be projectional editors as far as I am aware. For vims or emacs out there - I don't think they mainstream tools which can tip the scale. Even now vim is considered a niche, quirky editor with very high barrier of entry. And still, they operate primarily on text.

Without tools in mainstream editors I don't see how it can push us forward instead of saying a niche barely anyone knows about.

Post reply on HN