Hacker News Reader

Comment by j_m_b | Hacker News Reader

Whenever this old debate comes up, I am reminded of this quote

“There's a good part of Computer Science that's like magic. Unfortunately there's a bad part of Computer Science that's like religion.” - Hal Abelson

I don't worry about indentation because emacs does it for me. However, if this is your personal pet peeve then you should provide all of your developers / contributors with a plugin, script or other utility that formats their code to your standards. This issue has long been solved programmatically and it is a waste of mindspace to deal with it any other way.

View on HN

> However, if this is your personal pet peeve then you should provide all of your developers / contributors with a plugin, script or other utility that formats their code to your standards.

http://editorconfig.org/

Interesting idea and it would certainly help to alleviate the "how many editors do we need to provide code style config for" problem, but it looks rather limited in scope at the moment (for instance it doesn't even try to address "brace on current line or line of its own", let alone more odd things like GNU coding style brace indent).

It's only really targeting text-editor-level settings, things like encoding, EOLs, and "what characters does the tab key emit". It doesn't attempt to solve every formatting/linting/style issue, that would make the editor plugins really hard to keep compatible.

You don't even have to do that. Just use whatever format is in the main repository. Then use git smudge and clean filters[0] to convert to your preferred format whenever git checks out the files. This way your editor does not need to care about the format everybody else uses.

[0] https://stackoverflow.com/a/2318063

That quote reminds me of one of Joseph Campbell's - "computers are like Old Testament gods; lots of rules and no mercy."

And to go along with that, some things like GNU Make still requires tabs, which is definitely annoying when you have your editor set to autoconvert. And some sects like Go or Python don't technically REQUIRE one or the other, but still try to aggressively purge the heretics.

Is that a limitation in GNU Make or is it an inherited limitation of m4?

In my experience, m4 is an arcane bit of software that surprisingly few people know about and one that frankly should have been replaced years ago.

Personally, I try to never use autoconf because of this.

Tab as the prefix for command lines is a property of all Makefile formats I'm aware of (though not of many other build script formats). Make itself (including GNU Make) does not generally use M4, though both Autoconf and Automake use it, often in conjunction with Make, as part of the Autotools suite which is also published by GNU.

So, none of the above, in itself. It is a historical anomaly which has been preserved.

I haven't dug into it, but Wikipedia claims that Make is actually about a year older than M4 (obviously not GNU Make).

    go fmt

Controversy solved for one language ;)

And clang-format[0] for C/C++, google-java-format[1] for Java, YAPF[2] for Python, rustfmt[3] for Rust...

[0]: https://clang.llvm.org/docs/ClangFormat.html

[1]: https://github.com/google/google-java-format

[2]: https://github.com/google/yapf

[3]: https://github.com/rust-lang-nursery/rustfmt

The parent post's point wasn't about add-on formats. The point was that the language spec it's /self/ has an included lint tool to eliminate controversy.

The go language has /a/ (single) correct formatting syntax.

TIL vim has been hiding this problem from me.

emacs' makefile-gmake-mode, loaded automatically for makefiles, also hides this. I've set indent-tabs-mode to nil in my .emacs for years, but the mode knows it's needed, and will indent the line with a highlighted tab ( until you begin writing in the command to follow it, when it unhighlights it ).

> which is definitely annoying when you have your editor set to autoconvert

Is this actually a problem? Every editor I've ever used has detected that I'm writing a makefile and has changed the indentation to tabs automatically.

This tabs vs spaces thing is a recurring joke and source of conflict on HBO's Silicon Valley, and I always thought having a raging debate over tabs and spaces was one of the less realistic things about the show. But what I'm hearing now is that my use of emacs has just left me out of touch with the really tedious stuff other people sometimes have to deal with.

Any proper IDE/editor has auto-indentation nowadays, so there's really nothing special about Emacs anymore. Obviously even with auto-indentation you still have to agree on the right convention for a given project. As with most code style debates, it usually doesn't matter that much one way or another as long as you make a call and keep it consistent across the project.

Ehh, I'd say emacs has a minor edge in that tab is a command to indent to the correct level, not to insert characters.

I.e., you can also use a single `tab` on an over-indented line to correct indentation.

Your point stands, of course.

Most emacs users would use ctrl-i instead of tabs or spaces I imagine, at least I do it like that. It is much easier to type.

Emacs still has a quirk that stands out :)

Only an Emacs veteran would say that ctrl-i is easier to type than Tab ;)

> I'd say emacs has a minor edge in that tab is a command to indent to the correct level, not to insert characters.

I've had this in basic code editors for... 10 years or so? It's hardly an emacs thing.

To be fair, this applies to vi/vim as well.

I hear it all the time. People saying things like "I use vi/vim instead of an IDE because I can do X" where X is a feature that every IDE worth using has had for 10 years.

I've literally had someone say that they use vi/vim because it does syntax highlighting. What were they using before? Notepad? gedit? Even gedit has syntax highlighting.

"Oh, I use this magical vim plugin that lets me hit this magical key combination and all my code gets automatically formatted." Yeah, but Visual Studio, PyCharm, Eclipse, and basically any other IDE do that out of the box. No plugins necessary.

I don't think I've ever seen someone describe a feature that vi/vim/emacs has that an IDE doesn't (EDIT: Other than the fact that every *nix system is going to have vi, but that's just an argument for knowing how to use it, not one for preferring it over an IDE if one is available). It's like iPhone versus Android about five years ago, where the iPhone fanboys/girls would praise Apple for their innovation for implementing features Android had over a year prior.

> I don't think I've ever seen someone describe a feature that vi/vim/emacs has that an IDE doesn't

Emacs can seamlessly access files over ssh, ftp and/or sudo.

Emacs lets me add custom hook commands to run before a file is saved (to check a file’s syntax using an external command), and after it’s saved (to signal reloading of the file to the relevant process).

Emacs also includes my mail reader, my diary, my organizer, a spreadsheet, an stack-based algebraic calculator, etc. but those may be unfair comparisons. :)

Note: All of the above are part of the built-in functionality of Emacs. Third-party extensions can of course do anything.

There's an argument that Emacs is a collection of extensions to lisp that happens to include a text editor

> I don't think I've ever seen someone describe a feature that vi/vim/emacs has that an IDE doesn't

Maybe this has changed in recent years, but in the past whenever I tried IDEs I would be amazed that they didn't have keyboard macros.

Most have support but it's usually supported via plugin API (trivial in most cases)

I find vims block highlighting (ctrl+v) very useful, never noticed it being part of an IDE.

That being said I don't think it's that big a deal but I've seen some fucking vim wizards churn out code faster than what's reasonable for human beings

The Jetbrains suite and Sublime text have this feature. Hold Alt while selecting with the mouse.

> I find vims block highlighting (ctrl+v) very useful, never noticed it being part of an IDE.

As far as I'm aware multicursors are a superset of block editing (i.e. multicursors can emulate block editing but the reverse is not true), so many (most?) modern IDEs can at least emulate block editing.

Modal editing? Of course, that's what vim plugins are for. Only Pycharm has it out of the box (as a setting) of the above mentioned IDEs.

Really? Do you have an example? I've never run into this before.

Not that it's hard, it's just that other editors haven't done it (that I've seen).

It's a little exaggerated on the show, but I've definitely experienced pretty heated discussions on the issue!

"Exaggerated" as he actually voices his extreme views. Many people look down on the people from the other camp but never actually say anything to not sound ridiculous.

Not to mention, ruining personal relationships over bikeshedding is rightfully considered utterly toxic behavior in the real world.

Well, I'm Team Space for sure, but I just think the environment should take care of that. I mean, who sets up their IDE so it inserts tab characters. Alternatively who goes about indenting their code by hitting spacebar multiple times?

For js (at least?) we now have Prettier [1].

It's already a must-have editor plugin for myself and any underlings. It's real nice.

[1]: https://github.com/prettier/prettier

Which itself is based off of gofmt and facebook's Reason.

More languages should provide standardized ways of writing and formatting code. It makes everything easier - from diffing to subjectivity.

> Which itself is based off of gofmt

In what way? It looks like a fairly standard formatter to me.

At least for javascript the 'standard' formatters are significantly dumber than Prettier.

    This issue has long been solved programmatically
    and it is a waste of mindspace to deal with it
    any other way.

I beg to differ. Aligning code is an art form. And different people like different styles. Your "whatever" approach is one. And there are many others.

Art or whatever it is subjective to decide which code formatting is better. As long as a single "code format actor" can transform different styles automatically then why one should care. I think most communities are having an agreement on which one they would like to choose and most of the times they chose the best style but doesn't mean one has to limit themselves into those formats anyway. Something like git push --code-style somestyle would be a relaxing.

Like programming itself aligning code is not an art form, at least not in where productivity and consistency is required, it's just a means to an end. In my opinion the art is in documenting your code and explaining what your code does (what you intend it to do not how it does it).

Sure, and writing the rules to feed to your linter and formatter is where the art takes place now.

I don't really care if you use tabs or spaces. Just please, for the sake of humanity, don't mix them.

Seriously, this is the heart of it. The one thing about Emacs that I just can't forgive is its insistence over the decades on mixing tabs and spaces in its auto-indentation.

Ultimately, the spaces vs. tabs debate really comes down to which policy is less likely to result in mixed tabs/spaces. If people use tabs, it seems inevitable that some spaces will sneak in there as well. If people use spaces, tabs are unlikely to sneak in. Obviously that's a combination of common default editor configs and human behavior, but that's just how it works out in practice.

this is my opinion, too. In an ideal world we would all use tabs so that we could all see the indentation level that suits us best. But it's not an ideal world. So we're forced to use spaces and agree on how many spaces to indent with.

Except for Go programmers.

Tabs for indentation, spaces for alignment. That's the only acceptable mixing.

It works because it allows everyone to configure their code editor to have tabs be whatever width they want without messing up how it looks for other people.

But it's futile. Unless there's a git hook setup or you're using Python 3 which throws errors when tabs and spaces are both used for indentation, you're gonna end up with source files with both being used.

> I don't worry about indentation because emacs does it for me.

The problem is, everyone's editor "does it for" them, but everyone wants to use a different editor. And there are interoperability issues when one person's editor produces tabs and another produces spaces.

It's a relatively minor tower of babel situation.

Well...the team tends to learn pretty quickly which editors don't follow the project's coding standards by default, and comes up with configuration files for those editors. If that doesn't happen, then inconsistent indentation probably isn't the first thing that needs to be addressed.

Reply on news.ycombinator.com