6 ms·

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

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.

rerdavies 3y ago
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.
- rusk 3y ago
  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.
  - TeMPOraL 3y ago
    > 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.
    - Etherlord87 3y ago
      > 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.
eviks 3y ago
The ugliness is simple indeed The code formatters aren't good enough (and also elastic tabstops work realtime)
deleted 3y ago
[deleted]
PhilipRoman 3y ago
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.
- flysand7 3y ago
  > 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

rerdavies 3y ago

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.

rusk 3y ago
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.
- TeMPOraL 3y ago
  > 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.
  - Etherlord87 3y ago
    > 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.

eviks 3y ago

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

deleted 3y ago

[deleted]

PhilipRoman 3y ago

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.

flysand7 3y ago
> 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