Live data from Hacker News

Formatting code should be unnecessary

maxleiter.com

471–480 of 484 posts

Re: Formatting code should be unnecessary

#471
post #316

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.

Because I spent the vast majority of the time I spent on code reading it , and the layout matters to me in terms of how much time it takes for me to read code. Yes, I can get used to other layouts, but that by no means means all layouts are equal to me in terms of how readable they are, and how well things stand out when they should, or blend in when they should. I recognise this isn't the case for everyone - some pe…

That's interesting. I also have aphantasia and I seem to be the only one around where I work that cares one bit about visual presentation. I suspect it's because people with aphantasia have to rely on waiting for visual recognition to happen so often that we get good at it and rely on it more. I'm also known for figuring out a problem and jumping to the exact file and area in the code that's causing it immediately where others apparently have to read through the code again to find it. I just remember it's maybe 2/3 the way through the file and just past that big switch statement and has a one-liner comment above it and has a distinctive shape.

For me, indenting with tabs and aligning with spaces helps me find the code that I'm looking for as does adequate whitespace and a color syntax highlighting editor. Aligning things with distinct columns where it makes sense helps a lot, too.

Re: Formatting code should be unnecessary

#472

Earlier quoted context omitted.

Yes, everyone has personal opinions about code vanity. When this becomes a holy war I really start to question the maturity of people on the project. I find that people worry about trivial nonsense to mask their inability to address more valid concerns. All that really matters is consistency. Let a team make some decisions and then just move forward.

> All that really matters is consistency And this is my problem. My last example, the 2 styles are inconsistent. So when the guideline is "all that matters in consistency" then I take that at face value. You though apparently pull back and believe something more messy. Effectively "All that really matters is a consistently applied style even if that style itself is full of inconsistency" The same applies to the trail…

> Without, the last line is inconsistent with the other lines.

The last line without a comma imparts the information that this line is expected to be the last line in the list which is something you don't get from it with that trailing comma. It's a small thing, but I don't like putting in that last comma because I'm effectively misrepresenting things for "syntactic sugar".

Re: Formatting code should be unnecessary

#473
post #316

Earlier quoted context omitted.

Because I spent the vast majority of the time I spent on code reading it , and the layout matters to me in terms of how much time it takes for me to read code. Yes, I can get used to other layouts, but that by no means means all layouts are equal to me in terms of how readable they are, and how well things stand out when they should, or blend in when they should. I recognise this isn't the case for everyone - some pe…

That's interesting. I also have aphantasia and I seem to be the only one around where I work that cares one bit about visual presentation. I suspect it's because people with aphantasia have to rely on waiting for visual recognition to happen so often that we get good at it and rely on it more. I'm also known for figuring out a problem and jumping to the exact file and area in the code that's causing it immediately wh…

Yeah, all of this matches my experience too.

Re: Formatting code should be unnecessary

#474

Earlier quoted context omitted.

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.

Did you read the example pietnas gave? The changed formatting ruined the communicative intent of his code. Formatters do that a lot, and it makes the code unambiguously worse. I don’t really care about whether the back is plywood or whatever. I don’t know how to write plywood code. I do care about creating clear, readable code that communicates my intent. Sometimes formatters help with that. Often they hinder, as the…

I don't see "pietnas" anywhere; do you mean the "important_numbers" example from maratc?

If so, I think a trailing comma is the correct fix, as described here: https://news.ycombinator.com/item?id=45168308

In this case I think the trailing comma is an improvement, so the formatter is steering you towards a better overall solution. However, even if you dislike the trailing comma, it's more important for the formatting to be consistent and robust, so I still think it's better to work within the limitations of the formatter.

Re: Formatting code should be unnecessary

#475
post #416

Earlier quoted context omitted.

>Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/et No, the argument is quite specifically that a one line diff to add a new argument/element to the end of a list is preferable to a two line diff to do the same thing. The presence of the trailing comma is necessary to achieve that only when elements are o…

Ok, we're then back to `print` example: print( 'Hello there from a very long line abcdefghijklmnopqrstuvwxyz', sep=' ', end='\n', file=None, flush=False, ) All of the existing named parameters to `print()` function are already provided, and that standard function is highly unlikely to change. Should I add another string to `print`, I will have to do it before the named parameters anyway. There is no sense in the trai…

I think this boils it down to the essence. Whether you use a trailing comma here, and whether you use single or double quotes, is just bike-shedding. If there's an automated tool that can make a consistent choice everywhere, that's worthwhile.

Re: Formatting code should be unnecessary

#476

Earlier quoted context omitted.

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

> 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. Okay, and what happens when you want to use version control? And what happens when people want to use other text editors? Or are you proposing that each language sh…

> Okay, and what happens when you want to use version control?

"This allows Git/GitHub to diff versions, and merge branches."

https://drcuis.github.io/TheCuisBook/Daily-Workflow.html

Back-in-the-day long-long-time-ago

ENVY Developer

https://www.google.com/books/edition/Mastering_ENVY_Develope...

Product Revew, ENVY Developer

https://archive.esug.org/HistoricalDocuments/TheSmalltalkRep...

Re: Formatting code should be unnecessary

#477

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

Back-in-the-day Digitalk VisualSmalltalk PARTS:

https://www.wirfs-brock.com/allen/files/digitalk/VSbrochure....

Re: Formatting code should be unnecessary

#478
Lua is especially annoying - even after years of using it I just can't really decide how to format it for better readability. lua-fmt sometimes works, often it makes it even worse. I welcomed Fennel in my Lua setups mainly because of this.

Re: Formatting code should be unnecessary

#479

Earlier quoted context omitted.

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…

Indeed, putting related code together in the same source file is one of the ways we cope with complexity. Though it too breaks down, because the relations between various bits of code may be so complex that there's no good way to "linearize" them. And you should be documenting your code, but documentation comments take up space on the screen since they are linearly arranged in the same file, so you see less functions…

> we should be able to do better than text files

https://gtoolkit.com/

?

Re: Formatting code should be unnecessary

#480

Earlier quoted context omitted.

Did you read the example pietnas gave? The changed formatting ruined the communicative intent of his code. Formatters do that a lot, and it makes the code unambiguously worse. I don’t really care about whether the back is plywood or whatever. I don’t know how to write plywood code. I do care about creating clear, readable code that communicates my intent. Sometimes formatters help with that. Often they hinder, as the…

I don't see "pietnas" anywhere; do you mean the "important_numbers" example from maratc? If so, I think a trailing comma is the correct fix, as described here: https://news.ycombinator.com/item?id=45168308 In this case I think the trailing comma is an improvement, so the formatter is steering you towards a better overall solution. However, even if you dislike the trailing comma, it's more important for the formatting…

I honestly have no idea where I read pietnas. The comment you identified was the one I was referring to.

I care about consistency, but not foolishly so. I suppose an important question is: under what circumstances is consistency undesirable?

I believe that consistency is not an end goal, but a means to achieve clear communication. When being consistent results in less clarity, it should be abandoned in favor of more effective communication.

Post reply on HN