Front-End Best Practices
Why did I decide to write this article and why following front-end best practices is important? Not to mention all the well-known aspects of why writing clean code and following design patterns is so important and how they directly influence the time and money spent on a project and how crucial it is to follow them…
All this critical time and money that should be spared might sound a little bit distant for a simple coder, but the truth is that we are developers - meaning that we actually develop: plan, build and extend applications. We craft. Of course, we are responsible for the code that we produce, but the reason why should every coder follow best practices is not only about responsibility - it’s also about the satisfaction of crafting something beautiful.
I’m convinced that every developer would like to write beautiful code. This article’s purpose is to promote healthy code habits and serve as one more kind reminder of the fact that we should strive for perfection.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry
I would like to suggest the following actions to become a better programmer and get even more excited about your results.
Decide on technologies you will use and create a powerful setup from the very start of the project.
I’ve read a joke once, “On your first day at the new job, squash every commit from the repo into a single commit with the message "Legacy code" and force-push to master.” There is a point - you should always consider rethinking and improving what you’ve been given.
Whenever joining an existing project, you should understand its architecture and see how you can improve it and plan it, document it if it’s the case. And it’s not only about new projects, but it’s also applicable to any kind of task - know what you are doing.
Don’t start working on something you don’t know how to achieve yet - ask for advice, look it up, envision your solution and then start with the implementation. And most importantly, if it’s a complex solution - design a separate scheme of the process, document it. In this way, you can be sure you won’t get confused later when you might forget your own approach. Also, this helps you make sure that all the coders that work on the project have the same understanding of the solution, and the newcomers will get accustomed to it fast enough.
Moreover, don’t build things you haven’t been asked for, but expect change and design your architecture considering that we live in an agile environment.
Following the common software design principles is a very good practice that every developer should have - no matter front-end or not. I believe it’s well-known that the code should not repeat itself (DRY principle), it is important to keep the code simple (KISS), it’s good not to write code that you’re not gonna need (YAGNI) and, of course, follow the SOLID principles.
There are many design patterns and following them could be difficult for a beginner. Therefore, you should start with a few, understand them and finally implement them in your code. You won’t be able to know when to apply which, unless you understand them. A nice starting point for diving deeper into design patterns is this article.
Some of the most widespread front-end conventions out there include the airbnb and Google Javascript style guides as well as the Idiomatic JavaScript principles and the Standard JS style.
Every project should have defined a style guide that every front-end developer or any developer should follow. It is one of the first must-read documents for coders when joining a project. If there is no project-specific code convention defined, then everyone should agree on an existing convention (similar to the conventions mentioned above). The more descriptive and detailed the style guide is, the cleaner and consistent the code would be.
I guess you might have heard the quote that “all the code in any code-base should look like a single person typed it”, no matter how many people contributed. Common conventions and standards help this statement come true.
JS is a multi-paradigm language, it supports event-driven, functional, and imperative (including object-oriented and prototype-based) programming styles. It has an API for working with text, arrays, dates, regular expressions, and basic manipulation of the DOM. Understand these paradigms, and the way they are applied in JS, so you can know when to use which, and most importantly - why. Never blindly do something you don’t understand.
Whenever you find something odd to you - be happy, because you can get better - so get documented and use the right paradigm feature for the right problem.
Plan the data structures, define them, use them and reuse them. It will help prevent getting confused with your data, especially when it is used across multiple components. Decide upon a backend data-mapping approach, to make sure that whenever the communication model between the front-end and Back-end changes, you don’t have to change a variable name all over your templates and scripts, but in a single place.
Try to optimize your data structures and their handling, just as the databases try to ensure the ACID principles: make sure you’ve got no redundancies and that the logic of storing the data is optimized. For example, whether you have a list with elements and only one element can be selected at a time - you can decide between two obvious approaches - whether to add an ‘isSelected’ property to every record or have a single ‘selectedRecord’ parameter. If you know for sure that there is a possibility to have many selected items in the future - use the first approach, otherwise use the second one as it is more concise.
In front-end frameworks, when you’ve got inputs and outputs your data structure may start losing its shape. Try to keep the same consistent type for the parameters that are used across your app.
Using a state-management library could be priceless when dealing with scalable data structures. It can prevent maintenance overkill and many bugs.
Have a single CSS methodology and follow it all across your project. Either you choose BEM, ACSS, OOCSS, SMACSS, or any other CSS methodology, stick to it and always give meaningful names to your classes.
Don’t constantly use “!important”, have a shame file and reduce its contents to a minimum.
The clean code is one of the most important practices that many developers get all wrong. Writing clean code is very important because programmers spend a lot of time reading the code, even more than writing the code. As programmers, we should always try to write not only working code but also clean code. We should always leave the code better and cleaner than we found it. It’s a good practice to write less code with more value - like today, simplicity is the ultimate sophistication, “less is more”, and we should keep it simple.
Yet, never be afraid to span multiple lines. You could find more about clean code in the book “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin and in this article.
And remember, clean code tends to bring more value than clever code.
This chapter should go under the Clean code section, I believe, but I think it is so important that I decided to put it on its own. Clean code is mostly achieved by meaningful names, and meaningful names, as we all probably know, are so hard to find. At least, have a naming convention so that all booleans, functions, classes, services and so on have a common, reasonable naming guide that never gets someone confused.
- Favor the verb-noun approach for naming methods, e.g. “getUser”, “setColor”, “parsePhoneNumber”, “deleteUserCard”
- Variables should be nouns, e.g. “userName” or “articles”
- Boolean variables should be named positively and start with “is”, which implies true/false, for example, “isActive” or “isSelected”
You’ve probably all heard the joke spread around by Phil Karlton - “There are only two hard things in Computer Science: cache invalidation and naming things.”
We live in a time when there are so many IDEs and so many modules to help tidy our code, format it and make it better. If it still happens for you to see mis-indented lines of code, know that there are many options to help you automate it. You can use linters to suggest you the right format or add pre-commit hooks together with linters to automatically format your code before each commit.
There are many IDE extensions that will help you format your code as you type it (on document save, or on a given manual command). Consider using any tools you like to have a correct and mainly consistent formatting across your project and make sure that all the team is on the same page with code formatting.
Code grouping should also be taken seriously. All the code formatting should be discussed at the beginning of the project and should be included in the style guide.
There are many sources on the internet that advice to comment the code thoroughly. There are also many sources that suggest not to write any comments at all so you will write a code so clean that comments won’t be needed.
My opinion on this matter is that if you choose to do write comments, then do not write useless comments, and try to reduce the comments to a reasonable minimum.
The code gets updated while the comments are often skipped and get out of date. Some comments are just simply useless because they bring you no more information than the code does. In terms of commented code - I would suggest to never keep such code on the master branch, or even the dev branch if you can. In most of the cases, commented code is just garbage that nobody is brave enough to remove, while in the remaining cases when you need to return to some code that was deleted - you can use the Version Control System.
If you choose the hard and rewarding way and choose not to write a single line of comments, then be aware that you should keep your code clean. I think it’s better to write dirty commented code than dirty uncommented code. So be aware, if you write no comments, you should make your intention in the code clear as water. And you’ll have all my admiration.
Nobody expects you to write great solutions from the first try, but you should not rely only on the fact that your code works. Refactoring is a code crafting stage that is a must. If you avoid refactoring, then you skip one of your professional duties. The flow is that you write a piece of code that works and then refine it to make it also comprehensible and neat. Simple is brilliant, so try to choose simple solutions - those are elegant and easy to follow.
Here are some clean code practices I would recommend adding in the refactoring stage as a front-end best practice (if they weren’t added before):
- Decompose the code into simpler components: have more small modules and functions that will respect the design principles: will have a single responsibility, will be reused and will not repeat themselves, etc.
- Favor pure functions, as they may spare you a lot of bugs, and help you write unit tests;
- Extract strings, “magic numbers”, hard-coded values into constants;
- Have a color palette and use color constants for SASS;
- Avoid z-indexes that differ from one another only by the count of 9’s, e.g: “999”, “9999”, “99999”, instead use constants for z-indexes and define a strategy;
- Have a config file for constants;
- Avoid deep nesting, as it is hard to follow, maintain and write tests onto;
- Use guard clauses and early return instead of nested conditions;
- Extract conditions (even simple ones) in a variable, to give it an explanatory name, so you can make the business logic more clear;
- Avoid always disabling the lint here and there. Either remove the rule that bothers you completely or have a very good reason why you need to disable the linter in a single place;
- Reduce the shame file contents to a minimum while refactoring;
- Make sure you follow the CSS methodology you’ve chosen all over your project;
- The code in a module should be read as a book, all the references should be close enough to follow them easily;
- Get rid of useless pieces of code: css classes, JS modules, functions, and files;
Use Test Driven Development... or at least do write tests! Whenever there’s a project in which tests are not in scope, I really suggest to make them at least low-priority, but in scope. Writing unit tests is usually part of the task, just as writing a coding solution is. It is a must to be able to write tests, know their importance and write them as clean as the usual code, it’s nice to have a high test coverage and, of course, a unit testing strategy.
In my experience, this aspect is rarely discussed, but the consistency must be followed in the Source Control Management as well - there should be a single common branching naming strategy and a single commit naming strategy per project.
Besides, it’s a must to have an SCM versioning & branching convention that will be clear for every member of the team. Write detailed commit messages.
Never blindly copy and paste code! You’ve got to read and understand it first, most probably you may even need to refactor it before integrating it into your codebase.
Review your colleagues’ code carefully and understand it. Don’t be afraid to ask, discuss or make remarks on the code, but be polite!
Don’t let the code get stale. Don’t be afraid to review the existing code and rewrite it, add unit tests to it and re-integrate it if it’s for a greater good.
When tired, the developers are prone to make way much more mistakes and produce more bugs than when fully rested. Constantly working overtime is a very bad habit.
That's why many countries think about implementing a 6 hours work day. If it happened to work late and there’s nothing you can do about it, take care to review your own code and the chosen solutions when you’re battery is full again.
This article about front-end best practices is aimed to inspire you to strive for perfection, write clean code and neat solutions. This is possible and easy when following best practices!
Thanks for reading the article, happy coding!
If you enjoyed reading this, you can also check my previous article:
