Live data from Hacker News

Formatting code should be unnecessary

maxleiter.com

311–320 of 484 posts

Re: Formatting code should be unnecessary

#311

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.

> So fix your setup? Why should others with wider screens leave space on their screen empty for your sake? What a terrible attitude to have when working with other people. "Oh, I'm the only one who writes Python? Fix your setup. why should I, who know python, not write it for your sake?" "Oh, I'm the only one who speaks German? Fix your setup. Why should I, who know German, not speak it for your sake?" How about doin…

Yes, I don't think we should discourage people from using Python or German just because you don't want to learn those particular languages either.

Working together with others should not mean having to limit everyone to the lowest common denominator, especially when there are better options for helping those with limitations that don't impact everyone else.

Re: Formatting code should be unnecessary

#312
post #105
post #103

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. Note that, in my mind, this visualization is not automatically generated, but lovingly created by humans who wish their code to be understood by others. It is not separate from the code, as typical design documentation is, but an integral part of it, stored in metadata. Consider…

> 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 Netscape, but alas ...

Re: Formatting code should be unnecessary

#313

Earlier quoted context omitted.

You're missing what the bike shedding metaphor is about. It's not about having bike sheds or not, it's about coloring bike sheds, which every day bike riders in their right mind really don't give a shit about, because it doesn't affect their life in any tangible way.

No, the original metaphor is they were planning to build a nuclear reactor and they spent significantly more time than expected on the details of the bike shed because it was simple to understand and change, unlike the details of the reactor which were complex and required expertise and had lots of constraints. Who cares what color the bike shed is, we're building a nuclear reactor here!

"Sigh, this guy is pedantically missing the...oh"

Took me a sec, but well played

Re: Formatting code should be unnecessary

#314
post #70
post #65

Earlier quoted context omitted.

Thats a slippery slope towards storing semantics and displaying locally preferred syntax ;)

And the bikeshedding has begun...

Who’s going to be bikeshedding (about formatting) when everyone can individually configure their own formatting rules without affecting anyone else?

Re: Formatting code should be unnecessary

#315

Earlier quoted context omitted.

some settings have advantages. For example, trailing commas on tables [ 'apple', 'banana', 'orange', ] has an advantage over [ 'apple', 'banana', 'orange' ] Because adding a new line at the end of the table (1) requires editing 1 line, instead of 2 (2) makes the diffs in code review smaller and easier to read and review. So a bad choice makes my life harder. The same applies to local variable declarations. Sorted lis…

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.

Don’t bother making decisions. Steal a standard. Vote on it once if you want to be democratic. Done forever.

Re: Formatting code should be unnecessary

#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 people read code beginning to end and it doesn't matter how its laid out. But I pattern match visually, and read fragments based on layout, and I remember code based on visual patterns.

Ironically, because I have aphantasia, and don't visualise things with my "minds eye", but I still remember things by visual appearance and spatial cues better than by text.

Re: Formatting code should be unnecessary

#317

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’ll go a step further. I’ve never understood why people care so much about the linter. Just let people write code and don’t worry about the linter. I don’t need to fight a linter which makes my code worse when I could just write it in a way that doesn’t suck. I promise it’ll be fine. I’m too busy doing actual software engineering to care if code is not perfectly formatted to some arbitrary style specification. I fee…

Everyone has their own opinion of what format doesn’t suck, so without a consistent code format, you’ll have to review diffs where fights over white space are mixed in with the meaningful change.

Re: Formatting code should be unnecessary

#318

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'm in the same boat. I have not run into any situations where someone's choice on formatting was bad enough that I couldn't read the code so ... just pick a format / standard and let's go. I'll get used to it if I'm not already.

Re: Formatting code should be unnecessary

#319
post #250

Earlier quoted context omitted.

Agree. There's a python linter named `black` and it converts my code: important_numbers = { "x": 3, "y": 42, # Answer to the Ultimate Question! "z": 2 } into this: important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question! This `black` is non-configurable (because it's "opinionated") and yet, out of some strange cargo cult, people swear by it and try to impose it on everybody.

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…

That’s an obviously terrible formatting change. A format that prevents scoping comments narrowly is absurd. Why not just tuck all the inline comments at the end of the file so the code is denser while we’re at it?

Re: Formatting code should be unnecessary

#320
post #78
post #64

Earlier quoted context omitted.

every editor can wrap text these days. good ones will even indent the wrapped text properly

> every editor can wrap text these days. could. Yesterday notepad (win 10) just plainly refused.

Windows is so weird
Post reply on HN