Sass Guidelines
This is a general guideline to write good and clean sass code. It mentions all the best practices. Also has a lot of links referring to other good resources
https://sass-guidelin.es
Sass Guidelines
An opinionated styleguide for writing sane, maintainable and scalable Sass.
28 Replies
i don't think that this is a good article to follow blindly
https://sass-guidelin.es/#syntax--formatting <-- it starts by talking about the intendation guidelines:
Roughly, we want (shamelessly inspired by CSS Guidelines): - two (2) spaces indents, no tabs; - ideally, 80-characters wide lines; - properly written multi-line CSS rules; - meaningful use of whitespace.at the surface, it looks good, but ... this is hell! writting code with space indentation is absolutely horrible, but i know this is subjective. also, the "80-characters wide lines" thing just needs to stop
Sass Guidelines
An opinionated styleguide for writing sane, maintainable and scalable Sass.
then it goes into strings and tells you to go against what css tells you to do, which is to use double-quotes on
@charsethttps://sass-lang.com/documentation/values/strings/ <-- the documentation itself uses double-quotes everywhere
Sass: Strings
Syntactically Awesome Style Sheets
then it tells you to just use double-quotes as an alternative to escaping
so, just ignore the advice of that document and stick to double-quotes
it also shows an example with division:
https://sass-lang.com/documentation/breaking-changes/slash-div/ <-- but that is wrong
doing this will stop working soon, as the slash is used as a divisor for many values
Sass: Breaking Change: Slash as Division
Syntactically Awesome Style Sheets
it does have good advice, like the list and map section
and it does go through the documentation, which is amazing
however, it does say some absolutely barbaric things about commenting:
Basically everything that is not obvious at first glance should be commented. There is no such thing as too much documentation. Remember that you cannot comment too much, so get on fire and write comments for everything that is worth it.at first, it seems pretty good advice, but too much commenting actually makes things a lot worse to read in the future and honestly, just don't use "loud" c-style comments, just use sass comments if you have a proper build system, you can generate a map with the sass code, and you can have less work for when you minify the compiled css, because it doesn't have to process the useless comments that were generated in the compiled code https://sass-guidelin.es/#mixins <-- this puts a date on the documentation
What do you say then? Tab indentation should be used? I do think tabs are better but the minimum gap is 4ch for a tab
the gap for tabs is definable on any proper code editor, but you should really just use whatever indentation method you want as long as it's consistent with the one your colleagues / collaborators use
tabs are the only choice, but whatever the team agrees is best
as jochem said, you can change it even in some consoles, so vi++ and vi# users dont have an excuse to bash on tabs
vscode lets you set it from 2 to 10 spaces wide
i think notepad++ lets you pick from 1 to 9 but im not sure
but whatever i say, in the end, it doesnt matter much
with proper tools, even dreadful spaces will behave like tabs
I am currently working in a small company where there is no other FE dev than me. So I am tasked with setting up the code format and style guides. I just want to understand what will be the most productive thing when we onboard new developers.
proper documentation from the beginning
setting up the environment and all that
guidelines for source code control as well
and then you can think about the code and ide
a spellchecker is mandatory
Oh I see I will look into that
remember: they cant do anything if they cant test what they produce
if you dont have confluence, you can use the github wiki
it is ... ok, for a free product
Oh it is from atlassian
yup
you can use gitlab wiki too
and everything is in the repo
Yeah gitlab wiki seems much better. Easy access
if you find it, with its clunky menu navigation
which is something you can hand them on the onboarding process
Yeah that seems good. Things cannot go right without proper documentation
exactly
trust me, the least of your problems is how your sass code looks like
you can drop a settings.json file in the workspace, if you use vscode, and that's all done
That is true in a way. I mean just by adopting sass, A lot of problems with writing css code vanishes. So I dont have to worry about css that much
exactly
but if the ide can do the formatting for you, there is no need for you to mandate this or that on anyone
tell them "use this" and done
Yup. Just add a formatter, and a settings json and that will be pretty much it.
precisely
And I think I will do just that since it is a small company, and We can tell devs to use a specific IDE for work.
Will make a lot of things easier for me
yes, and for everybody else
if they dont like the ide, they can use whatever, as long as it produces the code you expect
and follows all your guidelines
but, we are deviating from the topic here, so, i dont know if this still counts as a good resource
Agreed. This resource Is infact a personal opinion of one dev. I think it just has too much of must do s'
honestly, in my negatively biased opinion, the resource is full of bias that make no sense, and some outdated examples that shouldnt be there, but has some pearls in the middle of it