Hacker News new | past | comments | ask | show | jobs | submit login

Yes, yes, yes. I'm saddened that tabs have essentially 'lost' - they seem to me in every way superior to spaces, but I would never use them in a new project simply because it would be likely to throw off others, and perhaps tooling. Github, for example, does not play nicely.



The proper way is tabs to the point of indent, and spaces thereafter. Even Github will work if you do that.


Github works better if you do that, agreed. But IIRC (I don't do this any more, so this is from memory) it uses eight space tabs as a default, and can only be changed on the 'raw' pages.


Spaces are superior to tabs in only one (important) way: They're a constant width.


Bam-bam-bam-bam. Sorry can hear you over all the whitespace I have to type.


Every editor worth its salt does this for you. Maybe try upgrading from ed.


"This is a good decision because we've forced every editor to handle this good decision well."


If only there was a way not to have to rely on editors all behaving the same with leading spaces. Oh wait, there is a way: indent with tabs.


I also prefer tabs. I'm just saying that "I have to wear out my spacebar" is not a good argument.


Yeah, indenting with spaces wastes so many punch cards! Oh, wait.


Actually, a punch card used to represent a single line.

But you'd be wasting holes.


Not that I've ever used one, but I wouldn't expect someone to indent any code on a punch card.

I just felt the comment was suiting since it must have been about when they were still used that you couldn't automate indentation.


In FORTRAN 77, it'a syntax error to put a statement before column 7


Interesting! Can you explain why that is the case? Were the first 6 characters reserved for the line number or goto marks?


Yes. Columns 1 to 5 are for labels. Column 6, if it has any character there (usually "$"), marks a continuation from the previous line.

I think the column 6 rule and line continuations were removed for FORTRAN 95.


They're superior only in C-like languages when you indent in constant-width levels, and then only if you use very short names in your code.

Try using tabs to indent e.g. arguments to function one under another, and weep.


> Try using tabs to indent e.g. arguments to function one under another, and weep.

Where the terms are distinguished in a programming context, that's alignment, not indentation; tabs for indentation, spaces for alignment is a common suggestion.


Sure, as long as you don't mix them on one line (i.e. first indent, then align), because then differences between tab widths will still break alignment.


Not if you do it right:

   \t\tsome_func(arg1,
   \t\t          arg2,
   \t\t          argN)
will look right no matter what the tab width is.


I just realised my invalid belief was caused by experiencing dumb editors in the past, which wouldn't recognise aligning and would turn your example into:

  \t\tsome_func(arg1,
  \t\t\t   arg2,
  \t\t\t   argN)
I.e. they would replace all sequences of tab-width spaces with a tab character.


First indent and then align will retain alignment with different tab widths, because you only align things that are at the same indent level, so different tab widths in a tab indent / space align combination just move the whole aligned block left or right without affecting alignment.


I stand corrected.


> Try using tabs to indent e.g. arguments to function one under another, and weep.

I despise that formatting, and use:

    fn_with_many_args(
        very_long_arg1,
        very_long_arg2,
        very_long_arg3,
        very_long_arg4
    )
which aligns fine with `\t\t`; so I shan't be weeping today, sorry! :)




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: