Best practices for interfaces in Typescript

Question

Best practices for interfaces in Typescript

Here's a question that doesn't have a clear-cut answer. I understand that coding styles vary greatly, especially among different languages - for example, camel case function names in JavaScript vs pascal casing methods in C#. I can definitely accept that.

Although it might be overthinking things, I'm delving into TypeScript and really liking what I see. I plan to use it with Angular2 and want to establish a solid style guide.

One thing that's puzzling me is point 2 here, which advises against using the "I" prefix for interfaces. Up until now, I thought this was almost a universal practice. I have a class called Car, so naturally, the interface name would be ICar. But now I'm conflicted about whether or not to follow this convention.

I'm open to following suggested practices, but this particular one has me unsure which direction to take.

Does anyone know why the common convention of using an "I" prefix for interfaces is discouraged in TypeScript? I understand that you can use any conventions you prefer, but I'm curious if there's a specific reason for deviating from this widely-adopted practice.

Any insights or opinions on this matter will be greatly appreciated!

typescript angular

Answer 1

Answer №1

At one point in time, using "I" as a prefix was popular in Java and C# (and possibly other languages), but it is no longer seen as a best practice. However, changing something that the majority of developers are already accustomed to using can be a challenge.</p>

<p>This trend is similar to hungarian notation, which is widely regarded as a bad practice. Instead of using prefixes, it is recommended to give variables and classes meaningful names. For example, if you have different types of cars, consider making "Car" the universal interface and creating classes like "FancyCar implements Car." This approach allows for more natural and intuitive naming conventions without relying on prefixes. You can read more about this concept here: <a href="http://c2.com/cgi/wiki?IntentionRevealingNames" rel="noreferrer">http://c2.com/cgi/wiki?IntentionRevealingNames</a></p>

<p>Some programming languages like Dart (and others) do not have a strict differentiation between interfaces and classes. In Dart, any class can implement another class, with the class' interface serving as an interface itself.</p>

<p><strong>Update:</strong></p>

<p>Naming variables and classes is often considered one of the most challenging aspects of software development. While there may not be a perfect solution, it is generally agreed among experts that using prefixes for technical reasons is not ideal. Instead, many developers opt for naming conventions such as <code>UserService

, UserServiceImpl, MockUserService. By following consistent naming practices throughout your codebase, you can ensure clarity and maintainability. It's also important to consider the common styles used in the programming language you are working with and adhere to those conventions.

Answer 2

At one point in time, using "I" as a prefix was popular in Java and C# (and possibly other languages), but it is no longer seen as a best practice. However, changing something that the majority of developers are already accustomed to using can be a challenge.</p>

<p>This trend is similar to hungarian notation, which is widely regarded as a bad practice. Instead of using prefixes, it is recommended to give variables and classes meaningful names. For example, if you have different types of cars, consider making "Car" the universal interface and creating classes like "FancyCar implements Car." This approach allows for more natural and intuitive naming conventions without relying on prefixes. You can read more about this concept here: <a href="http://c2.com/cgi/wiki?IntentionRevealingNames" rel="noreferrer">http://c2.com/cgi/wiki?IntentionRevealingNames</a></p>

<p>Some programming languages like Dart (and others) do not have a strict differentiation between interfaces and classes. In Dart, any class can implement another class, with the class' interface serving as an interface itself.</p>

<p><strong>Update:</strong></p>

<p>Naming variables and classes is often considered one of the most challenging aspects of software development. While there may not be a perfect solution, it is generally agreed among experts that using prefixes for technical reasons is not ideal. Instead, many developers opt for naming conventions such as <code>UserService

, UserServiceImpl, MockUserService. By following consistent naming practices throughout your codebase, you can ensure clarity and maintainability. It's also important to consider the common styles used in the programming language you are working with and adhere to those conventions.

Answer 3

Answer №2

Here is a related question that discusses the confusion surrounding TypeScript coding guidelines for interfaces and classes: Understanding Interface and Class Coding Guidelines in TypeScript

To see my detailed answer, click here:

Key Points to Consider:

The era of Hungarian notation is no longer relevant
The use of prefixes like 'I-' goes against the encapsulation principle
Good names serve as a shield against poorly named elements
Choosing appropriate names can dispel the myth that an interface acts as a contract

Answer 4

Here is a related question that discusses the confusion surrounding TypeScript coding guidelines for interfaces and classes: Understanding Interface and Class Coding Guidelines in TypeScript

To see my detailed answer, click here:

Key Points to Consider:

The era of Hungarian notation is no longer relevant
The use of prefixes like 'I-' goes against the encapsulation principle
Good names serve as a shield against poorly named elements
Choosing appropriate names can dispel the myth that an interface acts as a contract

Answer 5

Answer №3

One should always adhere to common coding practices and standards in order for their code to be easily understood by others. It is important to follow the conventions set by the language being used to ensure consistency.

When it comes to not using prefixes in interface names, there are several compelling reasons:

Introducing prefixes to explicitly declared interfaces creates confusion as some interfaces will have prefixes while others won't. This inconsistency can make the code less readable and harder to maintain.
The compiler treats types (interfaces) and variables as separate entities, so there is no need to prefix interface names to avoid conflicts with variable names.
Using a prefix like 'I' for interfaces is akin to systems hungarian notation, but it doesn't add any meaningful information to the code for the developer writing it.

Answer 6

One should always adhere to common coding practices and standards in order for their code to be easily understood by others. It is important to follow the conventions set by the language being used to ensure consistency.

When it comes to not using prefixes in interface names, there are several compelling reasons:

Introducing prefixes to explicitly declared interfaces creates confusion as some interfaces will have prefixes while others won't. This inconsistency can make the code less readable and harder to maintain.
The compiler treats types (interfaces) and variables as separate entities, so there is no need to prefix interface names to avoid conflicts with variable names.
Using a prefix like 'I' for interfaces is akin to systems hungarian notation, but it doesn't add any meaningful information to the code for the developer writing it.

Answer 7

Answer №4

Two additional reasons

Organization into Modules As the project expands, it becomes necessary to organize the code into modules. The primary objective of modularization is to define clear contracts and conceal the internal details. These contracts are typically defined using interfaces, leading to the exposure of interfaces and factories in the codebase. It is more user-friendly for module consumers to interact with entities like Users and Credentials rather than IUsers and ICredentials

Alphabetical Sorting For efficient navigation, arranging Interfaces and Classes alphabetically in a file navigator can greatly enhance productivity. When dealing with Users, having entries like User, UserService, and UserImpl grouped together simplifies the search process compared to scrolling through entries starting with I, then C, and finally Service

Answer 8

Two additional reasons

Organization into Modules As the project expands, it becomes necessary to organize the code into modules. The primary objective of modularization is to define clear contracts and conceal the internal details. These contracts are typically defined using interfaces, leading to the exposure of interfaces and factories in the codebase. It is more user-friendly for module consumers to interact with entities like Users and Credentials rather than IUsers and ICredentials

Alphabetical Sorting For efficient navigation, arranging Interfaces and Classes alphabetically in a file navigator can greatly enhance productivity. When dealing with Users, having entries like User, UserService, and UserImpl grouped together simplifies the search process compared to scrolling through entries starting with I, then C, and finally Service

Best practices for interfaces in Typescript

Answer №1

Answer №2

Answer №3

Answer №4

Similar questions

Ways to include x-api-key in Angular API request headers

Exploring the location of unit testing within async-await in Angular applications

ngModel Error: Unable to retrieve the 'name' property of an undefined value

Challenges when transitioning from Angular 8 to Angular 9

Tips on ensuring a <video> element occupies the full height and width of the screen

Prevent users from clicking buttons until all mandatory fields are filled out using react-hook-form

Styles applied in the child component will have a cascading effect on the entire webpage

Can an attribute be assigned to an Angular host element without specifying a value?

Encountered a hiccup during the deployment of an Angular application on Heroku

Enhancing Connectivity between Angular and Electron

The type 'Promise<UserCredential>' cannot be assigned to

Discover the location of items within an array

Ensuring that all environmental variables are properly set in Typescript by utilizing interfaces and resolving union to tuple type discrepancies

Ways to dynamically emphasize text within ngFor loop

When transitioning the Next application to Typescript, errors are displayed with JSX, but it functions correctly in the browser

Mastering GraphQL querying in React using TypeScript

Snackbar and RTK Query update trigger the error message: "Warning: Cannot update during an existing state transition."

Challenges with Angular observables

Tips for exporting/importing only a type definition in TypeScript:

The 'formGroup' property cannot be bound as it is not recognized as a valid property of 'form' in Angular 7