Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

Clarify ident rule #13

Closed
Bartvds opened this issue Aug 15, 2013 · 9 comments
Closed

Clarify ident rule #13

Bartvds opened this issue Aug 15, 2013 · 9 comments

Comments

@Bartvds
Copy link
Contributor

Bartvds commented Aug 15, 2013

I'm not really sure what ident is about. Is it supposed to check indent levels? What about them?

We use tabs for indenting, and I cannot get this rule to give helpful info.

I think this rule or another could check for indenting consistency, maybe also like smarttabs in JSHint.

@ashwinr
Copy link
Contributor

ashwinr commented Aug 15, 2013

indent checks for indentation consistency within statement blocks. Currently, a tab character is treated as 4 spaces, but we can make it configurable if necessary. Take a look at the indentation test if you really want to understand how the rule works.

@Bartvds
Copy link
Contributor Author

Bartvds commented Aug 16, 2013

I think there is a bug that was part of my confusion, looks related to the one-line literals:

With this rule:

"indent": [true, 4],

In this snippet (with tabs)

        getKey(label:string, keyTerms?:any):string {
            return xm.jsonToIdent([label, keyTerms ? keyTerms : {}]);
        }

I get these 2 errors (line 75 is the indented line):

>> src/git/GitAPICached.ts[75, 27]: unexpected tab width: expected 16, got 0
>> src/git/GitAPICached.ts[75, 34]: unexpected tab width: expected 16, got 0

@Bartvds
Copy link
Contributor Author

Bartvds commented Aug 16, 2013

This one is interesting as well. This the content of a single file:

module xm {
    export function callAsync(callback, ...args:any[]) {
        process.nextTick(() => {
            callback.apply(null, args);
        });
    };
}

With this error: (line 6 is is next-to-last-one with the };

>> src/xm/callAsync.ts[6, 3]: unexpected tab width: expected 4, got 0

Notice the }; is my mistake, the semicolon doesn't belong there (as the brace is from a named function). If I remove the semicolon the rule passes.

@ashwinr
Copy link
Contributor

ashwinr commented Aug 16, 2013

Fixed the indentation rule to allow one-line literals always. so, the first example above should work.

@ashwinr
Copy link
Contributor

ashwinr commented Aug 16, 2013

there's not much we can do about the second one. the single semi-colon is treated as an empty statement, and tslint complains about it not indented correctly (which is a valid complaint, IMHO). In general, we advise tslint to run after the tsc compilation succeeds, so we don't get tripped up by compiler errors, but there's not much we can do in this particular case.

@ashwinr ashwinr closed this as completed Aug 16, 2013
@Bartvds
Copy link
Contributor Author

Bartvds commented Aug 16, 2013

Cool, I understand. I had tslint before compilation, as it is a lot faster then compiling. But I can see how that'd could go wrong, I'll swap it.

Note the noempty doesn't warn about this particular case though (in my 0.2.1)

@ashwinr
Copy link
Contributor

ashwinr commented Aug 16, 2013

but there's no empty block in your example, right?

@Bartvds
Copy link
Contributor Author

Bartvds commented Aug 16, 2013

Ooops, you are right!

I was confused with your mention of 'empty statement' (which there is between the closing brace and the semicolon, but that's not this rule).

@ashwinr
Copy link
Contributor

ashwinr commented Aug 16, 2013

cool :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants