Interface naming

[skulptur]

https://github.com/mediamonks/frontend-coding-standards/tree/feature/readme#naming

Documentation doesn't say anything about always starting with an uppercase i (for example ICoreComponent), or if interfaces should never use that.

[ThaNarie]

I think the intention is to not prefix anything, although it's not explicitly stated indeed.

While I agree with that in general, there are cases with more OOP style setups where classes and interfaces they implement have the same name, and the prefix is useful. Not sure how easy it is to find another name for the interface that doesn't conflict, since naming is hard :D

[psimk]

I am fairly sure that the I prefix came from the older times of TypeScript, when Interfaces and Types were distinctively different in their uses. Nowadays, a type can pretty much do anything an interface can, so that distinction is no longer needed. type is a bit more flexible, so it generally should be used over interface almost always.

The only exception being are projects, which are OOP and have multiple layers of class abstraction, whose definitions would benefit from an implementable interface.

[ThijsTyZ]

We used the I prefix back in the days for ActionScript (Flash). Because within ActionScript you always need an interface and a class that implements it. Therefor you can get name conflicts because an Interface and class cannot have the same name.

With TypeScript you don't need both, because an object or class don't need to explicit implement an interface to be as the interface. And in TypeScript you an use a class as interface or do typeof to dynamically create an interface on object or import a class as a type. Therefore you barely need both an interface and a class of the same name, so you don't run into naming conflicts.

So no prefixing of anything is needed. Do you think we should explicitly put that in the documentation?

[ThijsTyZ]

And if we are going to enable StrictPascalCase for classes and interfaces (see #9 ), it's not even allowed to have two uppercase characters following each other in a name.

[ThaNarie]

Therefore you barely need both an interface and a class of the same name, so you don't run into naming conflicts.

Barely is not never. Sometimes a class has more methods that you want on an interface, so you want both; the interface with the minimal implementation, and the class that implements it.

I agree that we shouldn't do it by default, but maybe it should still be allowed. Not sure if the linting rule can configure exceptions :)

[ThijsTyZ]

If a project needs an exception, you can always overwrite some rules for that project. I would not add an exception by default.

[ThaNarie]

For sure, but it depends in how much harm the exception can do.

In this case, it seems to tricky to configure (if possible at all without an consequences), so fine my me :)

Action point remains:

• [ ] Update the docs to reflect that interfaces should follow the exact naming rules as classes, and should not use the I or any other pre- or postfix.