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

381–390 of 484 posts

Re: Formatting code should be unnecessary

#381

Post by theamk »

sublinear wrote: post #15
accelbred wrote: post #13

Earlier quoted context omitted.

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.

Nobody wants to have to run their own formatter rules in reverse in their head just to know what to grep for. That defeats the point of formatting at all.

You'd need all-news tools for non-text world as well.

So the real choice is either:

- new tool: grep with caching reverse-formatter filter.

- new tool: ast-grep with understanding of AST serialization format for your specific language.

At least in the first case, you still have fall back.

Re: Formatting code should be unnecessary

#382

Post by hliyan »

oftenwrong wrote: post #368

Storing an IR also means we can create languages beyond the limits of syntactical practicality. Imagine, for example, an entire comment/documentation dimension of the code. Instead of commenting on a line near some code, you could attach comments semantically to an expression, or to a variable, or to any unit of code.

Token, statement and block level annotations would actually be nice. Perhaps even nicer if those annotations could be structured data instead of just text. You could create a truly self-describing code base without having to worry too much about the second hardest problem in programming.

Re: Formatting code should be unnecessary

#383

Post by kolme »

robertlagrant wrote: post #362
kolme wrote: post #338

Earlier quoted context omitted.

I did that when I was young and naive. I'll tell you why I did it. I thought I was very smart. Like, really really smart, maybe the smartest programmer in the team. And as such my opinion was very important. Maybe the most important opinion in the team. Everyone had to listen to it! That is all. Also, I was wrong.

> Also, I was wrong. This is probably the only useful takeaway, but can you explain why you were wrong?

Yes, I was wrong on several levels.

First and foremost I was wrong thinking that I was smarter than others — that's not even how intelligence works.

Second I was wrong being so stubbornly pro-tabs / anti-spaces (for example). It doesn't make that much of a difference, so there's no point in being so passionate about it.

And third I was wasting everyone's time (and my persuasion powers) by not choosing my battles more wisely.

My suggestion would be nowadays: let's choose a popular style guide, set up a linter and be done with it.

Re: Formatting code should be unnecessary

#384

Post by ryandrake »

AdieuToLogic wrote: post #107
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'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…

Thank you! I am almost going out of my mind reading this ~200 comment thread with everyone just casually saying "linter" when they mean "formatter". Do people really not distinguish between these two very different programs?

Re: Formatting code should be unnecessary

#385

Post by rafaelmn »

zokier wrote: post #226
gr__or wrote: post #206

Earlier quoted context omitted.

Text surely is a hill, but I believe it's a local one, we got stuck on due to our short-sighted inability to go into a valley for a few miles until we find the (projectional) mountain. All of your examples work better for code with structural knowledge: - grep: symbol search (I use it about 100x as often as a text grep) or https://github.com/ast-grep/ast-grep - diff: https://semanticdiff.com (and others), i.e.: hide…

But as the tools you link demonstrate, having "text" as the on-disk format does not preclude AST based (or even smarter) tools. So there is little benefit in having non-text format. Ultimately it's all just bytes on disk

Why even have a database - let's just keep the data in CSVs, we can grep it easily, it's all bytes on a disk.

Re: Formatting code should be unnecessary

#386

Post by _mu »

stavros wrote: post #123
AdieuToLogic wrote: post #107

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…

Right, but it's obvious they meant "formatter".

Why build understanding when you could be pedantic?

Re: Formatting code should be unnecessary

#387

Post by globular-toast »

I feel like squeezing out every possible place for people to be creative and express themselves creates a pretty boring environment. Like, imagine if all buildings were just purely functional. They'd all be the same grey box shaped things. I recently worked on a codebase that was lovingly developed by a single maintainer and had all kinds of weird and wonderful quirks that made me smile every so often. I'm a pretty serious person most of the time but I'm not going to lie it made my day that little bit more interesting.

Re: Formatting code should be unnecessary

#388

Post by lisper »

Jach wrote: post #245
benrutter wrote: post #148

Earlier quoted context omitted.

Scanning the comments waiting for a lisper to comment and found one! I guess lisp still has whitespace? That seems like the only meaningful way it isn't already just what the post is describing.

In actual Common Lisp development, code is stored in text files and edited and diffed as text in source controlled repositories. Once code is evaluated by an implementation, it's a different story, but before that there are many formatting options. It's mostly around where to put line breaks, whitespace, and parens, but still. The other day I wrote this simple function: (defun check-password-against-hash (password ha…

> In actual Common Lisp development, code is stored in text files and edited and diffed as text in source controlled repositories.

That's true, but there is a very big difference between S-expressions stored as text and other programming languages stored as text because there is a standard representation of S-expressions as text, and Common Lisp provides functions that implement that standard in both directions (READ and PRINT) as part of its standard library. Furthermore, the standard ensures READ-PRINT equivalency, i.e. if you READ the result of PRINTing an object the result is an equivalent object. So there is a one-to-one mapping (modulo copying) between the text form and the internal representation. And, most importantly, the semantics of the language are defined on the internal representation and not the textual form. So if you wanted to store S-expressions in, say, a relational database rather than a text file, that would be an elementary exercise. This is why many CL implementations provide alternative serializations that can be rendered and parsed more efficiently than the standard one, which is designed to be human-readable.

This is in very stark contrast to nearly every other programming language, where the semantics are defined directly on the textual form. The language standard typically doesn't even require that an AST exist, let alone define a canonical form for it. Parsers for other languages are typically embedded deep inside compilers, and not provided as part of the standard library. Every one is bespoke, and they are often byzantine. There are no standard operations for manipulating an AST. If you want to write code that generates code, the output must be text, and the only way to run that code is to parse and compile it using the bespoke parser that is an opaque part of the language compiler. (Note that Python is a notable exception.)

Re: Formatting code should be unnecessary

#389

Post by ParetoOptimal »

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 promise after a week you'll just get used to whatever format your team lands on.

Arthur Witney formats like this:

    C vt[]="+{~
If your code was formatted automatically like that, do you think you'd get used to it after a week?

My point is there is meaning of how code is formatted and there is an effect on understanding for certain people.

I think that at a certain point of "reasonable" and for most "normal" people your statements hold true, but I don't want anyone to think that every person caught up on formatting is just doing it for bike-shedding or other trivial reasons.

I don't know what is actionable if what I say is true, but it feels important to say.

Re: Formatting code should be unnecessary

#390

Post by fallpeak »

ParetoOptimal wrote: post #389
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 promise after a week you'll just get used to whatever format your team lands on. Arthur Witney formats like this: C vt[]="+{~ If your code was formatted automatically like that, do you think you'd get used to it after a week? My point is there is meaning of how code is formatted and there is an effect on understanding for certain people. I think that at a certain point of "reasonable" and for most "normal" people…

The unreadability of that example has approximately nothing to do with code formatting, which is generally understood to refer to modifying the textual representation of the code while leaving the actual logic more or less unchanged. Can you propose some alternative whitespace or indentation scheme which would make that example significantly more readable?
Post reply on HN