Using tslint as recommended by Thinkster

[adriatic]

If you’re using TypeScript, there's a good chance you're using TSLint and benefitting from some of the rules in the recommended settings. But there are so many more rules we can add that aren't included by default. Whether you're doing greenfield development or maintaining a legacy code base, a good portion of our job as a software engineer is reading and comprehending existing code.
The following list of TSLint additions focuses on readability and organization. Additionally, having stricter rules helps with onboarding new developers, and keeping a consistent code style. Some of these items may seem like a hassle at first, but are well worth the effort.

To eliminate part of the pain for any VSCode users, you can set TSLint auto format on save to handle the majority of linting issues. With the TSLint extension installed, go to settings.json and add the following configuration:

"editor.codeActionsOnSave": {
    "source.fixAll.tslint": true
  },

So without further ado, here are the list of additional rules I recommend:

Member Ordering

Organizing our code so we know where to expect methods, properties etc. is exactly what adding member ordering does. Furthermore, it comes with a few predefined config options such as ‘fields-first’ to focus our fields/properties to be declared at the top of our classes. However, you can customize this for whatever standard your team wants to follow.

More Info: https://palantir.github.io/tslint/rules/member-ordering/

Newline Before Return

Part of readable codebases is separation of concerns. The action of returning something is unique and should have a line to separate it from the logic. This rule requires a new line before return statements. It’s worth mentioning that no new line is added if it is the only statement in the block which is nice as we want to intentionally space out our logic, but not just add lines for the heck of it.

More Info: https://palantir.github.io/tslint/rules/newline-before-return/

Max File Line Count

This is one of my favorites and harder to add to an existing project, but when starting greenfield development, it's a must. It gives you the ability to set a max file length for a TypeScript file. It encourages building smaller and single responsibility components and functionality. My personal preference is to have a max line of 300. One thing to consider is that you need to be true to its intent, so when you near that limit of 300, don’t shorten the code just to make it within the limit, but take another look if some items have grown out of scope and need to be their own file.
More Info: https://palantir.github.io/tslint/rules/max-file-line-count/
Member Access
One of the primary reasons to use TypeScript is for readability. But the other is to be explicit in our declarations and definitions. Member access allows us to force explicit access modifiers, thus ensuring there is no accidental leak of class internals and leading to more readable code bases.

More Info: https://palantir.github.io/tslint/rules/member-access/

File Name Casing

How the project is setup is almost as important as the code that goes into it. Filename casing enforces strict file naming convention. It has all the predefined types you would expect such as ‘camel-case’, ‘kebab-case’, ‘pascal-case’ etc. Not only that, because there are always exceptions to the rule, it is possible to have a regular expression ignore certain files when necessary.

More Info: https://palantir.github.io/tslint/rules/file-name-casing/

Prefer Template

ES6 gave us some great items and template strings were one of them. When doing string concatenation it forces template strings rather than concatenating with a bunch of ‘+’ signs leading to more readable string. It also has a setting to allow a single concat if you don’t want to jump all the way in, but do want to get your toes wet.

More Info: https://palantir.github.io/tslint/rules/prefer-template/

There are quite a few other TSLint additions than could make this list, but they're a bit more controversial in nature and a bit more difficult to add. Like with any standards, it's best to think and weigh the pros and cons, but generally I lead towards "the stricter the better". Considering the number of devs that will touch a code base over its lifetime this seems to be the best route.

If you liked what you read and want to learn a few more tricks, you can find more of my content at:
• YouTube
• Self-Taught or Not Podcast
• LinkedIn

• Dylan Israel
  Senior Software Engineer at PwC, Mentor, & Educator

Dylan's Courses on Thinkster.io
• 100 Algorithms Challenge
• 100 Frontend Interview Questions Challenge

Find this email helpful? Forward it to a friend. Get this forwarded to you? Signup for my newsletter here.
Happy Coding