Console logs
Delete.
It's important to remove console.log in production code to prevent sensitive information leaks and enhance performance.
Console errors and warnings
Investigate and fix.
It's important to address console errors in production code to maintain a smooth and error-free user experiences.
Any in TypeScript
Do the correct typing.
Using any in TypeScript should be minimized in favor of explicit types to enhance code reliability and maintainability.
Comment unused code
Delete.
Commenting out unused code is bad practice as it clutters the code, hinders maintenance, and may lead to outdated comment information.
Super Components and Functions
If your component is large, the time has come to divide it into smaller components.
Think about the good old principle of SOLID called Single Responsibility.
Whether you are writing functional or class code.
Rewrite CSS multiple times
For the love of Ada Lovelace, Alan Turing and Tim Berners Lee...
Don't rewrite colors, fonts and sizes repeatedly, use design tokens to your advantage, create global CSS variables or use libs.
Talk to your team about the advantages of using design tokens.
Flags to ignore Linter
Example: use /* eslint-disable @typescript-eslint/no-unused-vars */
Fix your code.
Don't send Pull Requests with linter errors.
If you really need to ignore, think carefully about which linter warnings you can do so.
Re-renders and loops consuming to many resources or crashing
Example: JavaScript loop functions or useEffect in React poorly applied.
This may cause infinite repetition in API calls or values that can overflow memory and crash your application.
Fix your logic.
- Note: your application runs in the browser and consumes limited end-user memory resources.
Business rules on the Frontend
Do not place and do not allow.
It is commonly agreed that any Frontend application cannot have business rules, only rules inherent to the user interface, for interaction and the user's successful journey.
Frontend is the client, not the server.
Large companies and enterprise-level applications adopt the practice of not exposing their business rules and data processing on the Frontend, placing them on the Backend.
- Note: for simple, serverless web applications or those that consult third-party APIs, it may be necessary to place some business rules in the Frontend - being careful not to expose sensitive or very costly processing to the client.
Culture of not testing
Make tests happen on your codebase. No code is perfect.
Unit, Integration, Security, UX, Performance and Accessibility Tests. Use testing tools to generate error reports and improvements to correct your application.
Example: Cypress, Lighthouse, SAST in the deploy pipeline, etc.
Work in partnership with the UX, QA and Cybersecurity/Pentest teams if they exist on your company.
Fear of communication
You are a human.
Please, whenever you are stuck, call another Dev or Technical Lead to share the problem you are facing.
Problems are solved faster through pair programming and thinking together!
Remember: They were once in your position and will help!
I hope you enjoyed! 😃✌🏻
Do you have any more TIPS?
Support my work ☕️ Buy me a coffee
Oldest comments (48)
The article is very well-written.
However, I think there are some exceptions to the Flags to ignore Linter.
For example, there are issues where ESLint errors are generated even though some function type declarations are not function implementations.
Thanks for this contribution Yeom, you are right! Sometimes the Linters go on crazy mode haha
Yes. There are exceptions and for those we can easily disable the linter message. But as a general rule I have my linting preferences in the global eslint json so whenever I really need to disable something is for a very good reason.
If you do Code-Reviews then make it a rule to always discuss overrides/ignores with the reviewer. If the Reviewer also is fine with it, it is okay. If not, then the reviewer and you will find a better solution.
Great post. I would also add to your point about minimising the use of the
anytype by suggesting the use of theunknowntype when more flexibility is needed without sacrificing type-safety. I wrote a great blog post explaining the difference between unknown and any in TS.Thanks for sharing your article Rajae!
Learning about the
unknownof TypeScript is really important😄
Just read 3 of your blogs. You’re a good writer. Well done with the amazing job.
Thank you!
Lucas, would you like to join WebCrumbs? I think you’d be a great addition. (Ps: I’m not a bot, I’m really impressed about the tips you posted here). Cheers!
Thank you for sharing..@
As a fresher it's really great to understand these things.
It will provide broader view
Nice Article! Thanks for sharing
Very well written. 👍
enjoy your posting!🔥
My questions is, still worth using:
I feel like those are all questions that need to be debated with the project team. None of them are wrong, they are just different paths that you and your coworkers can take based on the project needs.
Technical decisions Peter! Decisions to do depending on the project, business needs and the team
This is the beautiful of Programming!
Those are very personal or project specific decisions to take. Their are preferences not good practice. I xan only say that for myself as lately I will go TS + React or Solid and I will always go functional first when writing JavaScript. There are very few exceptions for me to write a Class in FE.
Thanks Raí!
I think you are talking about the reference to the SOLID principle of Single Responsibility.
I updated the post to make it clear: whether you are writing functional or class code.
For good code maintainability, functions cannot be super functions full of logic. It is better to divide them and each one responsible for one thing.
For example, when we make components in React, which are essentially functions, it is also not good practice to create giant components, as the Atomic Design methodology proposes very well.
Lucas, I think you misunderstood my answer to Peter's question as a comment to your post 😉... he'd asked if people prefer to go HTMLX or a JS Framework. I just gave my current preferences of now : React And SolidJS (NOT to be confused with SOLID principles 🙃) .
Also as a preference, I prefer to use Functional first vs OOP when writing JavaScript. This has nothing to do with code quality. BOTH paradigms allow people to write bad code... and BOTH will allow you to write good/maintainable/SOLID code😉.
That will only depend on the entity located between the keyboard and chair. We were not talking about components.
PS: Se olhar pro meu comentário sobre o post vai ver que assino em baixo de tudo que escreveu. Mas espero que você não tenha essa noção que oop é melhor que funcional... idealmente em código funcional as tuas funções são puras, sem mutações e efeitos colaterais. Ou seja muito mais fácil de se atingir o princípio de responsabilidade única 🙂
If you need type safety you would still need to use typescript, even with jsDoc, but the decision would depend on your project needs prob..
From what I've heard and seen HTMX is good if you want to avoid having a dedicated front-end stack, and just inject a bit of reactivity into your server side app.
What a well-written content with great tips, thank you.
I found interesting the no-use of comments in order to "delete" code, I'd say that there might be a way to "comment" the code without deleting it by using git. Saving the changes after makimg them, so if they don't work, we could get back.