You should automate that issue and have an autoformatter on every commit. Everything else is a waste of time

Honestly, I feel like we should have gone further and decoupled display and serialisation formats of code a long time ago. (Although I understand why we haven't.)

A lot of people without much programming experience seem to really struggle with nesting. We take it for granted, but I suppose it actually involves some reasoning about evaluation order of arguments.

For those people, persuading them to indent can be the difference between them having a chance of learning the knack or just flailing randomly, getting frustrated, and giving up.

(The other lesson is: if you're building a DSL for non-programmers, try to avoid putting in nesting and make everything really flat instead.)

Beautify for Brackets/atom works great. Should be a standard thing in editors really.

Some older books are the worst with indentation. Instead of learning to code you spend most of the time figuring out where the code block ends.

Wouldn't it be nice if all languages made indentation significant?

Or at least included a tool to fix it.

Vim has a nice command to fix indentation from the beginning to end of file: "gg==G (include the dblquotes)

Emacs does the same with C-x h TAB, or you can mark a region manually and reindent its contents with TAB.

As with vim, this depends on being in the right major mode for the language you're working with, which should be automatic for most languages (except Perl, which is screwy, because of course it is), and depends also on that major mode knowing how to cope with the code and being configured the way you want, which should be reasonably trivial for most languages (except Perl, which is screwy, because of course it is).

(Assuming that vim knows how to indent the language you're editing and in the way that you want)

Just don't uncritically apply this to all files without thinking twice and also consult with your team. :-/

Messing up indentation deliberately in few places is a good way to gauge their reaction and would you like to work with them.

Please don't do that sort of thing -- unless you give the candidate a piece of code and specifically ask what could be improved.

But don't expect candidates to spontaneously criticize the interviewer's code. Yeah, I know, you want to work with people who can think critically etc, but at the time of interview you aren't coworkers and aren't on equal footing. Personally, if I as a candidate see you writing code with bad indentation I will conclude either (a) you were making a point about e.g. correctness or efficiency and didn't bother to indent because it's literally throwaway code, so mentioning the indentation would be a distraction; or (b) you and your team don't care about indentation at all.

i just create an editorconfig file <http://editorconfig.org> in root directory of projects, saves having to remember to switch tab settings across them (there might be another plugin with more functionality but it does what i need it to)

This is half a solution at best. It doesn't specify whether to put the curly brace on a new line for instance, and a dozen other formatting options.

yeah, i meant for the tab issues specifically since others arent as easy to miss

hopefully someone will get around to adding more functionality to the plugin so i don't have to edit my visual studio formatting settings for parentheses/comma spacing whenever i switch projects :p