I came prepared to fight the author, but I left in agreement.
Yes, we should expect better from our tools and languages.
Formatting code should be unnecessary
421–430 of 484 posts
Re: Formatting code should be unnecessary
#422Earlier quoted context omitted.
100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for…
Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.
It’s actually Java, where the “+” is necessary.
Re: Formatting code should be unnecessary
#423Earlier quoted context omitted.
Saying this is clearly superior means you don’t keep your lists sorted. A sorted list is as likely to add something to the beginning as the end, where this solution has the same problem.
The only correct syntax/format [ , a , b , c ] If only there existed a language designer intelligent enough to support it
Lisp:
(
a
b
c
)Re: Formatting code should be unnecessary
#424> It's 2025, how are we still dealing with this sort of thing? You have to get everyone set up to use it, whereas everyone is already, of necessity, set up to use plain text. And we aren't all using the same programming language and the same hardware setup. Thus, specifically: * everyone has to agree on an IR standard; if it can't accommodate every programming language, then there needs to be coverage for all the pro…
What "everyone"?
They don't have to agree on anything.
The poster child for this is Smalltalk. An untraditional environment despite being around 60 years. The source code is stored locally in an internal file tied directly to the runtime image. You can export/import code through "traditional" avenues, but not just anything, it needs to be structured source code. You can't readily move raw text in and out.
Despite this impedance mismatch with "the rest of the world", ST folks have been developing code and collaborating for decades. They even manage to get things accomplished.
Also, consider many of the modern logging platforms that are logging to databases rather than just raw files. While some grouse about that, others manage to make do. Letting the structured log managers handle the lower level details and provide a better UX.
The game is to make sure that your UX for your system is capable of the task, not worrying about interoperating with everyone else.
Re: Formatting code should be unnecessary
#425I 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…
Drop a link!
Sorry for the late reply, here you go:
Re: Formatting code should be unnecessary
#426Earlier quoted context omitted.
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…
Its interesting that despite the utility of S-Expressions, as mentioned, semantic diff, for example, of CL code is uncommon.
By that I mean highlighting the diff between these:
(dolist (i l)
(print (car i)))
(dolist (i l) (print (cdr i)))
I'm pretty sure this exists, but it's uncommon (at least to me its uncommon).
Re: Formatting code should be unnecessary
#427Earlier quoted context omitted.
Yes, so much this! I've often wished that formatters had some threshold for similarity between adjacent lines. If some X% of the characters on the line match the character right above, then it might be tabular and it could do something to maintain the tabular layout. Bonus points for it's able to do something like diff the adjacent lines to detect table-like layouts and figure out if something nudged a field or two o…
I believe some formatters have an option where you can specify a "do not reformat" block (or override formatting settings) via specific comments. As an exception, I'm okay with that. Most code (but I'm thinking business applications, not kernel drivers) benefits from default code formatting rules though. And sometimes, if the code doesn't look good after automatic formatting, the code itself needs to be fixed. I'm sp…
I'm used to things like `// clang-format off` and on pairs to bracket such blocks, and adding empty trailing `//` comments to prevent re-flowing, and I use them when I must.
This was more about lamenting the need for such things. Clang-format can already somewhat tabularize code by aligning equals signs in consecutive cases. I was just wishing it had an option to detect and align other kinds of code to make or keep it more table like. (Destroying table-like structuring being the main places I tend to disagree with its formatting.)
Re: Formatting code should be unnecessary
#428Earlier 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…
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?
Lately I've switched to the terms "check" and "fix" because more and more formatters (at least in my bubble of Python and Go) are incorporating fixes. So not just rearranging code and maybe adding a comma here and there.
Re: Formatting code should be unnecessary
#429I 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…
My singular problem with visual programming is simply the amount of detail necessary in modern programming.
Code is flat out complicated, with lots and lots and lots of steps, each with perhaps even more detail.
And it's hard to do that efficiently with visual editors. Imagine a display with instead of thousands of lines of code, you have thousands of symbols.
Or, the visual editors break things down in to components that are so small they do not convey the "big picture" well.
It's a personal complaint with the way Smalltalk works. Lots of methods, small (ideally) snippets of code, all viewed in isolation.
It's common (at least for me) to put related code together in the source file. It's useful to scan the whole file to get a feel for the flow of the code, and the system. Looking at isolated code, out of context, has always been a struggle for me. There's a reason my code is not sorted alphabetically by function name.
Maybe if you organized code visually, that is, perhaps the upper left is the start up code, the lower right is some core math all collected together like beads in a pot. "All red ones go here, all the 1" ones go there".
Granted I have not worked on such a tool or such a project. But the linear presentation of code as structured text has worked well for me, even when I bounce around between modules in the IDE.
Re: Formatting code should be unnecessary
#430Typing keywords letter by letter is unnecessary too. Think about ZX Spectrum keyboard allowing you to type BASIC keywords with just one key press.
This was actually a potential problem, at least on Commodore machines.
On those machines you were able to abbreviate keywords.
At the same time, they support full screen editing. That meant you could just cursor up over some code, make changes, hit enter, and the changes would take place.
However, when using the abbreviations, it was possible to create lines that were too long. I don't recall the specifics, but there was a line limit for BASIC input. Lets say it was 80 chars (for discussion).
Using abbreviations (like ? for print) and you could end up with a line that would LIST for more than 80, but if you tried to change it with the screen editor, the lines would be too long, and truncate silently.
So you had to be cautious with your use of the abbreviations.