Because in an ideal world, readability and maintainability would be the north star of every programmer.
TL;DR
Make your TS Config as strict as possible so you can agree on naming conventions, avoid typing errors, etc
Use a linter and formatter tool so your team can focus on the real deal
Agree on a project architecture
Leverage the power of pair programming to solve complex issues
Don't try to abstract so much that your teammate (and, most likely, your future self) cannot understand your code later. When working within a team, often the most critical issue is to read and understand other people's code. Focusing on readability and maintainability will not only help you read and refactor your code in two months from now, but it will also help the whole team to be more productive, efficient, and, overall, happy!
Readable and maintainable codebases are also key when it comes to scaling your application. When starting a new project, it is better to start simple and small with strong and clear foundations rather than over-engineering your application without even knowing where your project will be in a few months from now.
But what can you do to make readability and maintainability your north star?
1. Make your TS Config as strict as possible
If you can, make your TS Config strict. You might have tons of errors, to begin with, but this is worth it as you will enjoy all the benefits of better type safety.
Here are some of the most useful rules you can enable in your TSconfig file:
"strict": the strict flag will enable a wide range of type checking, therefore, resulting in stronger guarantees of program correctness. If you turn this on, you will enable all of the strict mode family options. If you want to enable only some of the strict family (see below), it is not necessary to enable strict.
"strictNullChecks": set this rule to truewill save you a considerable amount of Javascript errors; especially the much-loved runtime error 'undefined' is not a function , frequently caused by bugs in JavaScript code. With strictNullChecksenabled, TypeScript won't allow you to use a variable that is not known to the compiler (an exception is to be made with the use of any typed variables, more on this later).
"strictBindCallApply": this rule is also super useful as it will check that the built-in methods of functions call, bindand apply are correctly invoked.
"strictFunctionTypes": if enabled, function parameters are checked more correctly. However, this rule doesn't apply to functions written in the method syntax, only for function syntax.
"forceConsistentCasingInFilesNames": enabling this rule will be useful if you are working on a project where developers use different OS because it will prevent issues related to the file casing and how the files are referenced in the code. TypeScript will thus issue an error if a program tries to include a file with a casing different from the casing on disk.
"noImplicitAny": TypeScript will issue an error whenever it would have found a type any. This rule is really strict and probably hard to implement in large codebases or codebases transitioning to TypeScript.
"noImplicitThis": TypeScript will raise an error if your code has implied any type of "this" expression.
"noImplicitReturns": if you enable this rule, TypeScript will check all code paths in a function to ensure they actually return a value.
"noUnusedParameters": enabling this will raise errors on unused parameters in functions.
For full reference, you can check the official documentation here.
2. Use a linter and formatter tool
Why is it so critical to have a TypeScript code that is readable, well-formatted, and clean? Because it will allow programmers to focus on what they do best and enjoy the most: implement business logic, improve performance, enhance the architecture of a codebase, build a UI library… you name it!
Using a linter and formatter tool (ESlint, Prettier…) will provide consistency to your codebase and make your team happier. And, we all know that a happy team is an efficient one! By keeping your TypeScript clean with linters and formatters, you are avoiding long debates among programmers regarding missing semi-colons or indentation (oh, joy!)
Your codebase will become:
easier to read and start with for new joiners
easier to review
easier to refactor
a happier place where programmers have fewer frictions
3. Agree on a project architecture
As Daniel Irvine pointed out in this article, 'almost always the biggest problem I see is interpersonal issues that stem from disagreements about project direction and structure.'
If you are working on a solo project or within a team, you will always be rewarded if you agree and follow a clear project structure. This will allow you to:
onboard new joiners more easily
navigate your project in a structured and clear way
find relevant files faster
better refactor your code as it will be easier to see the bigger picture within your project
overall, enhance your productivity and happiness with working on your project
4. Use the power of pair programming to solve complex issues
Why should you consider pairing with a teammate more often? For many good reasons!
It's fun and creates bonding within a team, which is not to be neglected as it will most likely improve the overall codebase in the long run.
It allows a faster and better spread of knowledge among teams, especially if the programmer leading the session is familiar with a part of the codebase the other teammate is not.
Along with the same idea, pair programming will allow a better transfer of skills towards junior developers as they can pick-up tips and tricks from more experienced developers, leading to faster growth.
Usually, when pair programming, you and your teammate are programming 'out loud', which ultimately leads to discover hidden items in the code and to a clearer understanding of the complexities.
Thanks for reading, and happy coding! 😀
Top comments (0)