When grouping selectors, keep individual selectors to a single line.
Don't prefix property values with a leading zero.
Lowercase all hex values and use shorthand hex values whenever possible.
Avoid specifying units for zero values.
Related property declarations should be grouped together following the order: position, box-model, typography, visual. misc.
Don't use
!important- It is a last resort generally and only use when you need to override something and there is no other way. Instead increase the specificity of the selector.
When a rule set includes only one declaration, consider removing line breaks for readability and faster editing.
Limit shorthand declaration usage to instances where you must explicitly set all available values.
Ensure your code is descriptive, well commented and approachable by others. Great code comments convey context and/or purpose.
Class names:
a. Keep them lowercase and use dashes to separate words
b. Avoid excessive shorthand notation. (.btnis fine,.sis not)
c. Use meaningful names: use structural or purposeful names over presentation.
d. Prefix classes based on the closest parent or base class.
Selectors:
a. Use classes over generic element tag for optimum rendering performance.
b. Avoid using several attribute selectors (e.g.[class^="..."]) on commonly occurring components. Browser performance is known to be impacted by these.
c. Keep selectors short and strive to limit the number of elements in each selector to three names over presentational.
Place media queries as close to their relevant rule sets whenever possible.
...
Top comments (12)
Hi Pritam,
FYI we've also added your blog post on a GitHub project gathering content about best coding practices :)
github.com/promyze/best-coding-pra...
Great content Pritam!
I've submitted your content to a Public Hub of best coding practices, here is the link.
Suggestion: if you want to write a "best practices" article, also explain the why of each one. There's so much to learn and it might not be seem evident. We don't need to be dogmatic about things.
Most of these are self-explanatory. Pls let me know the ones you didn't understand, I'll try my best to explain those.
I've pretty much seen each one of these hints and I know the reasons behind them, so personally I don't need a further explanation. Mind you, they're not bad advices at all, but the point is that for a beginner they might seem dogmatic.
Especially if you consider the goal of these practices. For example, the first one is about readability, but the second advice actually makes the code less readable - although more compact. Other practices are about code organization, others about performances, one is also about a common pitfall. This is all quite jarring.
In the end, my personal suggestion is that you shouldn't assume something you say is "self-explanatory" when directing at the general public, since the reader's experience may vary. A lot.
You've made your point. I agree with all the things concerning you.
I just hope the guys who don't understand the points mentioned in the post, they can always comment on the post to seek guidance/explanation.
That way it only underlines that, we are a dev "community"!
Just want to let you know that #3 is not lowercase in the image.
And while I agree with the tips (and I have been doing it like this for a long time already), I also agree with Massimo. It would be good to explain why.
Another tip: there are also linters available that can help you with sticking to a specific style. Like
stylelint.Thanks for pointing out the issue. Updated it!
Amazing article !
Thank you Aya!
#2 is surprising because leading zeros enhance readability. What is the reasoning behind no leading zero?
In that case honestly I don't think there is much difference between one and the other. It comes down to personal/team preference. Remember these are just guidelines/best practices followed by a specific team.
Some comments have been hidden by the post's author - find out more