Introduction
As TypeScript has grown in popularity, developers have embraced it for its type safety, scalability, and powerful tooling i...
For further actions, you may consider blocking this person and/or reporting abuse
Good sum up.
This is my experience and opinion, but I don't use: 6. Define Return Types Explicitly.
I do it only when there is more than one return type. If a single type is expected, and the function is clear about it, then I leave it out. TypeScript is good with it. It makes the code more readable (for me). Simple functions stay nice and clean without too much pepper included into the code, staying closer to JavaScript.
If you do unit tests and code coverage, then these simple return types are fast covered, too. The IDE also gives hints about the return type.
That is, of course, possible with simple projects/code with less developers, or just one, and trust in their skills. For bigger teams I also suggest more strictness as a rule for safety and consistency.
The thanks for the article. 🙂
Your Welcome @damian_cyrus
This article feels AI generated again. Do NOT use enums in TypeScript, check out this actually well written article which explains why: totaltypescript.com/why-i-dont-lik...
I came to the comments to say exactly this. Do not use enums in TypeScript. In fact, never use TypeScript syntax when JavaScript syntax will do the trick.
Absolutely, that’s a solid approach! Using plain JavaScript syntax in TypeScript where possible keeps the code simple, more flexible, and easier for others to read and maintain. TypeScript’s strength really shines when it enhances, rather than complicates, JavaScript. Thanks for sharing this, it’s a great reminder to stick with simplicity where it serves best!
Also feels like comment responses are ai generated..even the absolutely and you are right exclamations are there.
Good list, but I disagree on number 6. One of the best things about typescript is how good it is at inferring types. This is way better than strictly typed languages, like Java, where the type system (severely) limits the implementation. You get the same amount of type safety without any of the frustration. Inferred doesn't mean its not typed. The only time I use explicit return types is when doing method overloading.
Great point! TypeScript’s type inference is indeed powerful, and leveraging it can make the code cleaner and often more maintainable without losing type safety. Explicit return types can sometimes feel restrictive, especially when TypeScript does such a great job of understanding context on its own. Thanks for highlighting this – it's a solid reminder to strike the right balance and only enforce explicit typing where it adds clarity or when overloads are in play. Appreciate your input! 👏
But... if you specify the return type - you also protect against unintended return types. I find it depends on the complexity. I don't specify for obvious - but do when it could have accidental drift.
Absolutely, that's a great point! Specifying return types can definitely serve as a guardrail, especially when working with more complex functions or code that could easily evolve and "drift" over time. It’s all about balancing clarity and flexibility—explicit types can be a safety net in places where the logic might change, but for simpler, more obvious functions, inference keeps things clean and readable. Thanks for adding that perspective! 👍
Strongly disagree with number 8. I would say don't use Enums. A much better system is to use something along the lines of:
`export const UserRole {
Admin = "ADMIN",
User = "USER",
Guest = "GUEST",
} as const
export type UserRole = (typeof UserRole) keyof UserRole`
For more thorough explanation:
blog.logrocket.com/why-typescript-...
medium.com/@alex.roh/typescript-en...
You make a solid case! Using as const with objects and keyof is often a much cleaner and type-safe way to define constants like user roles in TypeScript, without some of the quirks that come with enums. This approach offers better flexibility and reduces potential issues when compiling to JavaScript. Thank you for sharing those resources—I'll take a closer look and keep this technique in mind for future posts! 👏
Really nice read NGL 🤝
10. Keep Functions pure....
Yeah I don't do that😅, there are functions that can perform side effects whilst still being easy to debug based on their naming. And even in the case of modules, side effects are ok. I'm speaking from game dev experience
7. Null Coalescing and Safety
Your implementation of it was very concise and shows the minimum potential for that in large scale project development
And yes, I define the return type of my functions🤓
Good article!
You're very welcome! 😊 If you have any more questions or need further insights, feel free to reach out. Happy coding! 🚀
Thank you very much.
Nicely compiled. Good one Yug!
You're very welcome! 😊 If you have any more questions or need further insights, feel free to reach out. Happy coding! 🚀
Your 9 doesn't follow previous rule no 6. How do you solve following both?
Use explicit return types on complex, reusable functions where unintended return types could introduce bugs—especially in large codebases.
For functions that need exhaustive checks (like switch statements on union types), you can let TypeScript infer the return type if the function is self-contained and straightforward. If the function grows or reusability becomes important, you can then add an explicit return type.
Great, thank you.
You're very welcome! 😊 If you have any more questions or need further insights, feel free to reach out. Happy coding! 🚀
Just amazing tips and tricks for making code nore effective, readable and easily understandable.
Thanks so much! 😊 Glad you found the tips helpful. Writing code that's both effective and easy to understand is always the goal. Appreciate the positive feedback! 🙌✨