This is how Chrome Dev Tools shows source code. The original is often minified or in whatever format the author left it. And when you check the "pretty" checkbox in dev tools, it shows up using whichever format Chrome developers decided it should look like.
Formatting code should be unnecessary
31–40 of 484 posts
Re: Formatting code should be unnecessary
#32It basically is, unless you’re in a whitespace-Nazi language like Python (no offense!). It doesn’t get much less formatted than Minified JavaScript, except maybe Perl or Brainfuck.
Minified JS often comes with mangling the names of functions, variables, etc... Formatters and prettifiers lack the ability to bring back the original names and meaning.
Re: Formatting code should be unnecessary
#33You can't easily search / grep etc. an IR, unless you use some kind of reverse translator. Readable source files have their benefits in being simple in that sense.
Imagine having to write a new diff tool for each language!
You don't need a special grep for every language, you just need a tool that translates the mini version into the formatted version and back. Then you chain the tools, just like anything else in UNIX.
Re: Formatting code should be unnecessary
#34Kind of a stupid take if you ever plan on sharing your code or using git.
Is it? When every developer has an IDE that can easily format the code in whichever the way they prefer, and minify it back just before pushing a commit.
Re: Formatting code should be unnecessary
#35Kind of a stupid take if you ever plan on sharing your code or using git.
Is it? When every developer has an IDE that can easily format the code in whichever the way they prefer, and minify it back just before pushing a commit.
No reason websites couldn’t let you choose how to view it like editors, either
Re: Formatting code should be unnecessary
#36The 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…
Exactly. This idea comes up time and time again, but the cost/benefit just doesn't make sense at all. You're adding an unbelievable amount of complex tooling just to avoid running a simple formatter. The goal of having every developer viewing the code with their own preferences just isn't that important. On every team I've been on, we just use a standard style guide, enforced by formatter, and while not everyone agre…
Yeah it would probably be a waste of time. It's a nice idea to dream about though. It would be nice to be able to look at some C# code and not have opening curly brackets on a separate line.
Re: Formatting code should be unnecessary
#37Re: Formatting code should be unnecessary
#38It never ceases to amaze me how many times people can essentially re-invent S-expressions without realizing that's what they are doing.
Wait until that Bablr user shows up to these threads, and then you'll really have to start drinking
Re: Formatting code should be unnecessary
#39The 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…
The entire OS was built around these source files. the unix philosophy on the other hand only "thrives" if every other tool is designed around (and contains code to parse) "plain text"
> 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.
Re: Formatting code should be unnecessary
#40Earlier quoted context omitted.
Imagine having to write a new diff tool for each language!
You don't need a special grep for every language, you just need a tool that translates the mini version into the formatted version and back. Then you chain the tools, just like anything else in UNIX.
Seems reasonable. Since you're likely to perform this translation more than once for any given file, it seems like it would be practical to cache the translated output, perhaps as a file on disk.