New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tabs vs spaces? #1709
Comments
There's no battle. Use tabs. |
I vote spaces! Let the internicine conflict begin! 😄 |
haha. we don't need that. But you know... we wouldn't be having this conversation if we were using tabs and every dev would still have his/her code perfectly aligned the way he/she wanted (2 spaces or 4 spaces). Just saying. |
I like tab. |
Spaces with indent size of 4 (VS defaults). |
If anybody feels like writing a TSLint rule to enforce a consistent style (eg: either tabs or 4 spaces but not both) then we'd run it in new tester (it has TSLint support). See also palantir/tslint#122 |
Spaces! FWIW JS libs use spaces (angular / jquery) This probably came about because of Crockford : http://javascript.crockford.com/code.html
Since TS is JS, we really should conform. |
Well, Crockford is a bit of a grumpy old guy so I take him with a grain of salt. There was a statistic on Reddit a while ago where someone analysed a decent chunk of Github and it was like 60% / 40% in favour of spaces. Myself and all the places I worked so far were tabs (although big part of that was AS3). It works totally fine. Code alignment is a waste of time but if needed smart-tabs work fine there too. The real bane I want to get rid of is mixed indents. Before we go thermonuclear on one or the other over the whole repo, at least it must be consistent per file. At some point we'll do #2228 but that's quite a big step (screws a lot of attributions so we can let @dt-bot do it). |
agreed |
If you're ever bored I advise reading the pull requests made to JSON.js. invariably they are submitted by people who don't know of Doug's slightly crotchety ways. They are all refused point blank :-) |
Just saw this : https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199-L213 the defaults are 4 spaces with tabs converted to spaces export class EditorOptions {
public IndentSize: number = 4;
public TabSize: number = 4;
public NewLineCharacter: string = "\r\n";
public ConvertTabsToSpaces: boolean = true;
public static clone(objectToClone: EditorOptions): EditorOptions {
var editorOptions = new EditorOptions();
editorOptions.IndentSize = objectToClone.IndentSize;
editorOptions.TabSize = objectToClone.TabSize;
editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
return editorOptions;
}
} |
How satisfying @basarat! |
The CRLF's are a bit stupid but whatever. Maybe we should just go for it. I'll try running typescript-formatter on everything and see what happens. |
Dear lord, what a slaughterhouse.. 562 total .d.ts files, with 446 files changed.. https://github.com/Bartvds/DefinitelyTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3
Heh. |
And did the tests too: https://github.com/Bartvds/DefinitelyTyped/tree/46f9d17b2b074c887bff35b06112070b28924248
Nice. So we have the technology, that was the easy part. But now need to decide if this is something we want because it will have some serious impact. For one line attribution is going to hell. And if we accept that then we should probably enforce formatting in the tester. I have TSLint setup in the tester (but it's disabled) so that can do a lot. Maybe we should improve the tester to a CLI util that can run the formatter and execute the tests, in a nicely usable way (it sorta works now locally but should be improved with clean CLI api etc). |
I say the sooner the better. But good news is that you won't loose the blame history. I wished GitHub had implemented this feature too in their diff view. |
Yea, but it sucks that |
@Bartvds, any response from GitHub?! |
So might take a while, if ever. |
I don't care what any of the supposed know-it-alls or style guides say – tabs for indentation are the only way to preserve the intent of the developer when alignment is involved. See my blog post about it. |
the code alignment (align on Also for public string FirstName { get; set; } => public string FirstName { get; set; }
public string Surname { get; set; } => public string Surname { get; set; }
public int Age { get; private set; } => public int Age { get; private set; }
private Address Address { get; set; } => private Address Address { get; set; } Add a new property and you need to reformat all these lines. Not a good code change to review. Your workflow might be different and might be allowing for this. It does make it much easier to read (code as art) but I haven't managed to experience teams moving tp it. |
It's the oddest thing. My instinctive reaction to idea of mixing tabs and spaces is to shiver and think "that's just filthy!" Completely irrational I know - but entirely sincere. Humans are weird... |
@johnnyreilly you are victim to a common misconception. Using tabs for indentation and spaces for alignment is NOT the same thing as mixing tabs with spaces. You clearly didn't read the blog post. Using tabs for alignment is why so many have been turned off from tabs at all, because people were doing it wrong. Had they been doing it properly in the first place, nobody would have noticed when they changed their editor's preference to display tab width at a different size. This is what the animated gif, above, is trying to demonstrate, how people have been doing it wrong. |
@basarat, I totally agree with you. I rarely work on projects with code alignment, but I do see it from time to time. If you could somehow enforce that developers on your project do not use alignment at all, then I'd say go for it. Otherwise, with spaces for indentation, there is no way for linting tools, among others, to distinguish between what was intended for indentation vs. what was intended for alignment, outside of parsing the code into CST (way overkill). Of course, there are host of other reasons not to use spaces for indentation in this modern age. Editors deal well with tabs, but they never have with spaces. Arrow-key navigation, delete, backspace – they just don't treat one indent of spaces like one unit. I've used Visual Studio, Sublime, PHPStorm and Notepad++, but they all have this fundamental problem with spaces for indentation. |
Navigation: I use ctrl + arrow keys. They hop spaces (all whitespace really) + words. For delete / backspace: For word selection I use expand word (ctrl+w from resharper defaults) and unexpand selection (ctrl+shift+w). I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). |
@jedmao actually I understood your point - I was just sharing my instinctive (and irrational) reaction. I didn't say it made sense 😄 |
@johnnyreilly gotcha. @basarat I use the for (var i = 0; i < 10; i++) {
if (i > 5) {
console.log('I am greater than 5');
}
} Say my cursor is at the beginning of line 3 and I want to navigate up to the beginning of line 2. Using your technique in Sublime, I could do it one of 2 ways:
In Visual Studio, the 2nd scenario can be reduced to 7 logical steps.
With actual tab characters, the shortest path is only 2 logical steps with no modifier keys. Couldn't be simpler.
I fail to see how word selection would aid in deleting or backspacing a spaced indent. I'm trying it in Visual Studio with no success. This is why I created the TabSanity Plugin for Visual Studio. Unfortunately, I'm not aware of such plugins for other editors. |
👍 I see your advantage. However as I edit this comment, ctrl etc works same as my VS so my habits carry over ;)
My bad, my description was confusing. Ignore the "word" selection bit. Just focus on |
What about : public string FirstName { get; set; }
public string Surname { get; set; }
public int Age { get; private set; }
private Address Address { get; set; } Wouldn't going from the beginning of |
@basarat I use
I, like you, also rarely, if ever, need to select inside whitespace. I never suggested that I would. I'm not selecting the whitespace, but navigating through it to get somewhere. Your alignment example above is definitely when I would use At the end of the day, what bothers me the most, is that you have to totally change your muscle memory when switching between a file with tabs for indentation vs. spaces for indentation. What's efficient (fewest logical steps) in a file with tabs for indentation simply does not work in a file with spaces for indentation. You could blame the editors for not giving you a seamless experience, but that's not fair because it's literally impossible (without CST) for editors to make assumptions in a file with spaces for indentation about what is an indent and what is alignment. What's even more frustrating is that it's so hard for people to recognize it. Spaces for indentation are pure evil... with horns. |
Final conclusion? I just want to contribute, what the heck are you using? |
@basarat the comic is wrong. We all know the Apple guy would use spaces and the Microsoft guy would use tabs. |
@jedmao I'm an ms guy and I use spaces :) |
I think #4211 is nice proposal. |
I would propose to use 2 spaces as done in the airbnb/javascript styleguide ... |
Suggestion: Use the coding standards set out by the library being typed. If the library being typed uses spaces, single quotes, and LFs, then do the same in the type definition. This way we can avoid the spaces vs tabs argument. The only problem is that it won't be easy to enforce this rule. If you need to enforce it and have full consistency, then I would recommend going with the most popular conventions. According to this website, it's spaces and single quotes. My personal preference is spaces (4) and double quotes, but I'm okay with using single quotes if it means that everything is consistent. Could the pro-tab and pro-tab-space users accept a similar compromise? |
@glen-84 purely for your amusement ... here why the compiler team used double quotes : microsoft/TypeScript#5811 (comment)
I personally go with single quotes myself as I find myself doing more and more TypeScript exclusively 🌹 |
I think it's also a bit more legible, and it was 57% vs 43% (not a big difference), but I guess you have to draw the line somewhere. =) |
I like @jedmao's point on tabs for indentation and spaces for alignment. Full disclosure: I'm coming from the Go-land where we have |
Spaces of course. Cause nobody knows how the tabs are exactly rendered in different editors if they are used elsewhere. |
@hinell why does it matter if tabs are rendered differently in different editors? It shouldn't, so long as tabs are "only" used for indentation. |
I prefer tabs, especially because of this: http://nickgravgaard.com/elastic-tabstops/ |
Turns out, there’s an even bigger reason to use tabs: developer accessibility. |
The repo was formatted consistently using dprint a few months ago, so this is settled. |
If was running some code against the definitions and was shocked how the repo is infested with mixed use of tabs and spaces.
We could organise a battle to decide on tabs vs space, but nobody wins there.
Maybe we should just stick with whatever style the original was created and enforce that?
I think we could combine detect-indent with TSLint in the tester (when we have #1314).
The text was updated successfully, but these errors were encountered: