Ask HN: Tabs or Spaces?

Semantically: tabs are simply correct. They encode actual meaning. Rather than merely presentation. They also win on accessibility, because someoen with visual difficulties can adjust their editor to display them as larger or smaller.<p>The counter to this is people using spaces for alignment, Like if one wants to list arguements below the openning backet of a function call, and line up the closing bracket.<p>The counter counter is: stop that. Adopt a style guide that doesn&#x27;t do alignment and sticks to a simple rule like &quot;Always indent once while within a multiline expression&quot; Alignment is for art. We don&#x27;t have time for your subjective view of what makes code pretty.

There are more important things to worry about.<p>If you are working on a team, do what the team does.<p>If you are working alone, do whatever works best for you.

There&#x27;s enough politics on hn right now, we don&#x27;t need to add religion to the mix ;)

Personally, I use tabs for indentation, spaces for alignment.<p>But more practically, I think the right thing to do is use an opinionated formatter (like Go&#x27;s gofmt or similar) and enforce that across the teams that you work with. Life&#x27;s too short to bicker about tabs vs spaces, when there are more important things to discuss like short variables vs long variables ;)

In practice, I don&#x27;t care, and I lol-ed at the religion comment below.<p>And I know tabs are seeing a comeback lately, but they are basically the only ASCII character that does not have a predefined width.<p>And the reason I dislike that is because they don&#x27;t have clear semantics even in the pure text-only world: eg. writing out a table in ASCII is not possible with these &quot;tabulating&quot; characters, because if the column data is wider than (tab-width – 1), well, there goes your alignment. And when something is so badly <i>defined</i> not to serve the purpose it&#x27;s named after, I can&#x27;t like it. :)<p>If it was called the &quot;indent&quot; character which was ignored anywhere but at the start of the line, it would at least be sane and consistent.<p>Incidentally, Emacs can do the right thing in most modes by turning tab <i>key</i> into the (re)indent command.

Both. Tabs up to the current level of indentation. Then spaces after that for alignment. Spaces never come before a tab, only after and only for alignment purposes.<p>Everyone likes to take a dump on mixing tabs&#x2F;spaces. But it solves all problems with both. Everyone can view the indentation width they prefer; 2, 3, 4, 8, whatever. And alignment is always correct no matter what width you prefer. An auto format tool can remove the need to manually deal with anything.<p>Indent width is a visual effect that should not be mandated. You wouldn&#x27;t mandate a color scheme for your code base, so why would you mandate indentation width?

From the guidelines:<p>&gt; Eschew flamebait. Don&#x27;t introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.

This is why every project should have a <i>.editorconfig</i> associated with it.<p><a href="https:&#x2F;&#x2F;editorconfig.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;editorconfig.org&#x2F;</a>

both!<p><a href="https:&#x2F;&#x2F;dev.to&#x2F;__shadz_&#x2F;tabs-vs-space-49l5" rel="nofollow">https:&#x2F;&#x2F;dev.to&#x2F;__shadz_&#x2F;tabs-vs-space-49l5</a>