Hacker News Reader

Comment by corbezzoli | Hacker News Reader

I don't find this useful. The alternative is simple:

- do not indent code that way

- do not align comments on the side

Before

    int someDemoCode( int fred,
                      int wilma)

    ×();                          /* comment */ 
    print("hello again!\n");      /* comment */ 
    makeThisFunctionNameShorte(); /* comment */

After

    int someDemoCode(
      int fred,
      int wilma
    )

    ×(); /* nobody */ 
    print("hello again!\n"); /* needs */ 
    makeThisFunctionNameShorte(); /* aligned comments */

This kind of control over indentation and alignment borders on OCD. You should be using a code formatter anyway, so indentation is auto-fixed.

View on HN

On the other hand

   int animateIndenting(  
      int startingIndent, ///  Starting indent, in spaces  
      int endingIndent,   ///  Ending indent, in spaces  
      int animationTimeMs ///  Animation time in milliseconds  
   ) {  
      ...
   }

is tempting. It's an interesting idea. Whether it's a good idea. It's hard to be completely objective when, for a brief time in the 80s, I spent one third of all my coding time maintaining elaborately baroquely indented Pascal comments. (Not my coding standard. It was fashionable at the time).

That the formatter doesn't replace tabs with space... quaintly optimistic. A great shame, since requiring that people use editors with this feature for all eternity, or have ridiculously random indentation of comments is a non-starter.

The key difference you are outlining here is form vs function. The latter example is perfectly reasonable because you are adding actual “content” and restructuring around that. I don’t think any reasonable person could object to that - coding guidelines bedamned.

GP’s example is just finicky window dressing based on indulging a personal aesthetic based on what the author things “looks good” on a particular day, with a particular font on a particular screen.

What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools.

EDIT > What happened to "code is primarily to be read, occasionally to be executed"?

Exactly this. Code should be readable for all. It goes through all sorts of other actors and tooling, not just your painstakingly configured IDE.

>> What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools.

> as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers …

All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against.

We have many, many coding standards most of which discourage tabs and fancy formatting but developers get special exemption because “ma creativiteh”

> plaintext code directly is an idea that needs to die.

Yes let’s throw out some things that work perfectly well to accommodate a few malcontent crybabies.

At the end of the day our laws and most of our written communication depends heavily on plaintext and that’s not gona change any time soon just because a few people don’t want to learn how to use it properly.

> What we should be striving for in code style is the lowest common denominator most bare bones structure that can be read, understood and modified with the most rudimentary of tools.

What happened to "code is primarily to be read, occasionally to be executed"? You're suggesting we should be optimizing for the wrong thing.

To be honest, this is just another unsolvable issue that's a direct result of us insisting on keeping the code as plaintext and insisting we work directly on it and only it, the single source of truth, using bare-bones tools.

It's really as dumb as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers, decorators, landscapers and others - were forced to use the same, single, canonical, flat technical drawing. You can imagine they'd be wasting much time on endless holy wars on the right drawing scale, right colors, line thickness, where to put the legend, how to make annotations, etc. - where the real problem is that a single flat piece of paper (or digital equivalent) can't possibly accommodate all their needs at the same time.

We're like that, and here we're discussing whether to align labels on the drawing to the left or to the right, in hopes it'll somehow make an impenetrably dense drawing an iota more readable. We're going as far as to play with dark monadic magick, inventing convoluted drawing techniques in order to somehow squeeze layout of cables, water pipes and air vents in a way that makes decorators shut up about not being able to visualize the building in their heads, because the plan is too dense or too non-local or whatnot. And we're so proud that we automated the ability to xerox the plan for different teams to add more squiggles independently, and then merge them into a new unified plan the next day, and even have an audit trail by putting SHAs on everything.

Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die.

> Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die.

I use Obsidian, because it's a cool notepad software that stores everything as plain text. This means at any point in time, if Obsidian stops being developed (and supported by up-to-date OSes), or there's a new better software, or stops being free to use - I can just stop using it, and I still have my notes. This is just one of many strengths of the plain text. Compatibility is another.

I know, I'm not actually editing those plain text files directly. I can, however.

Plain text as a storage format is fine; it's inefficient, but has longevity benefits you mention.

Plain text as representation to read, write and edit is also fine - many things are best expressed this way, and text lends itself to be edited efficiently by advanced tools (e.g. vim, Emacs, or sed, awk, etc.)

The issue is not with either of them alone. The problem seems from using the same plaintext documents for both storage and representation simultaneously.

The solution is to have a storage format optimized for storage - which could just as well stay plaintext - but all reading, writing and editing to be done through tools that render you a representation best suited for what you need at the moment. This could be plaintext prose now, plaintext code an hour from now, and a pile of editable, graphical state machine diagrams tomorrow.

> The solution is to have a storage format optimized for storage

Plaintext is for interchange not storage. You can optimise for storage by putting .gz on the end of it.

> writing and editing to be done through tools that render you a representation best suited for what you need at the moment.

XML? XSLT?

This has been tried and it’s easily done if you want nobody to like you.

The crux of the issue is interchange. Neither of the things you have so vociferously decried. As usual, somewhere in the middle.

The lowest common denominator is plain text and that’s what works best en masse for all the participants and tooling.

> All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against.

This is a huge logical error. You just proposed to use the lowest common denominator, but then your response to the analogy is that other people are constrained by rules. Yes, they are constrained by rules, that are very complex, and even then, the constraint ensures a minimal standard, it doesn't block you from creativity. Fire prevention rules will define how wide a corridor has to be, but it won't forbid you to build a wider corridor or to paint its walls.

BTW editing your post to answer a post below you wasn't the smartest thing to do…

No I meant the standardised approach is the lowest common denominator. It’s the least common unit that has been agreed upon. Category Error at worst, but well within colloquial bounds.

The ugliness is simple indeed

The code formatters aren't good enough (and also elastic tabstops work realtime)

I've found that code formatting in general is massively overrated. Same with consistent function naming. Once you get over the initial OCD it is quite liberating to not be bound by any rules. And with languages such as C you end up mixing all kinds of naming conventions anyway.

What matters much more are idioms, matching interfaces and descriptive names.

> What matters much more are idioms, matching interfaces and descriptive names

Once you get over that as well, it's also quite liberating to not be bound by rules. This does go into unlawful-chaotic territory for some people though

Reply on news.ycombinator.com