Tslint: rule suggestion: disallow "I" prefix in interface names

Created on 20 Jul 2015  路  14Comments  路  Source: palantir/tslint

https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#names

Do not use "I" as a prefix for interface names.

now, tslint has interface-name rule. but it is not a TypeScript team recommended.

interface-name enforces the rule that interface names must begin with a capital 'I'

if I create the pull request, will you accept it?

Easy P2 Fixed Rule Suggestion

Most helpful comment

@fandy I for one would welcome the PR. I had actually carried over the standard I-prefix from C# but after having read through a lot of the _current_ naming conventions and standards it seems that interfaces not being prefixed with "I" has become widespread enough to consider it _the_ standard. Added to the fact that the TS Team does not choose to prefix with "I" for a variety of reasons it just lends more credit to the argument against it. Whether everybody agrees that just because something is the status quo it should be followed, it still doesn't change the fact that it has become the status quo and this linting rule only serves to confuse new TS developers that want to adhere to that. TLDR I think it's time we change this rule's default behavior/setting to not require the "I" prefix.

All 14 comments

What would you be enforcing? That _no_ interface names start with I? What if the name being used just happened to start with I (like interface IncrementalDom or something)? I don't think that enforcement makes sense as a core rule.

If it _did_ go in to the core rules, it wouldn't be a new rule, it should be an option on the existing rule.

for example, I want enforce use ServiceProviderClass instead of IServiceProviderClass.
https://github.com/borisyankov/DefinitelyTyped/blob/master/angularjs/angular.d.ts#L29

rule is simple. If name[0] === "I" && name.substr(0, 2) === name.substr(0, 2).toUpperCase() equal true, lint to be failed.
the major case will not be a problem.
if problem occured, we can use rule flags individually. (e.g. IDInfo falls into pitfalls..

:+1:

:+1:
Suggest to change the implementation to check for lowercase 3rd character too. Because if I base on Framework Design Guidelines (http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development-ebook/dp/B0017SWPNO/ref=dp_kinw_strp_1), 2 characters shorthand would be in caps. i.e. if the name is longer than 2 characters, the first 3 characters would be in caps.

Cool, we'd be open to a PR for disallowing the I prefix. Not sure what a great option name would be if we want to retain backwards compatibility with the current config. [true, "no-prefix"] or [true, "no-i-prefix"]?

One option might be to permit regexes for enforcing name formats. However this sounds like it could get complex quickly and has the potential to slow down linting a lot. Having limited options that most people in the community can agree on has the advantages of consistency and fewer decisions to make.

Another downside to regexes: they're a pain to specify as a string (which is how you have to specify them in a JSON file). Not that we should completely avoid them, and for simple ones (as most would be in this case) it's not too bad either.

:+1: on no-prefix It is probably common enough to understand no-prefix of "I"

:+1: for no-prefix.
I do not know the problem other than I. Do we have a prefix should be prohibited in the other?
I think regexp is over performance. remember YAGNI.

1037 is merged :wink:

Why is this in place? Probably the worst linting rule I have ever seen.
I have a project with tons of interfaces that start with the letter "I", now that I want to publish to @types, I have to refactor my code?

@ORESoftware https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#names

It REALLY annoys me when I see an interface name starting with "I". This is TS, not C#. Java has very good arguments against using "I" as a prefix.

In Java, I is used so you know it's an interface and not a class. It's a useful paradigm. The same paradigm could be used in TS, but "no we want to be special". What is reason to not use I? Literally I can use any letter in the alphabet but I? How dumb is that.

馃憤Looks like the default is still to prefix with I. I'm happy to submit a PR to change this.

@fandy I for one would welcome the PR. I had actually carried over the standard I-prefix from C# but after having read through a lot of the _current_ naming conventions and standards it seems that interfaces not being prefixed with "I" has become widespread enough to consider it _the_ standard. Added to the fact that the TS Team does not choose to prefix with "I" for a variety of reasons it just lends more credit to the argument against it. Whether everybody agrees that just because something is the status quo it should be followed, it still doesn't change the fact that it has become the status quo and this linting rule only serves to confuse new TS developers that want to adhere to that. TLDR I think it's time we change this rule's default behavior/setting to not require the "I" prefix.

Was this page helpful?
0 / 5 - 0 ratings