Loomio

Styleguides

JH
Jonne Haß Public Seen by 367

So looks like we want to establish coding styleguides and actually enforce them. Let's try to find one that we all like.

Tools

We recently enabled Hound for Javascript. That should settle JSHint as linter for Javascript. Hound supports Ruby and SCSS linting too, through Rubocop and and scss-lint respectively. Those seems to be flexible tools, so let's settle on these too and enable Hound for Ruby and SCSS too.

Ruby

Rubocop defaults to the bbatsov styleguide plus some additional checks not specified there. Hound changes some of Rubocops defaults, unless you specify your own config, to match the thoughtbot styleguide. I can not fully agree to either, however bbatsov's provides a good base, especially since Rubocops defaults are modeled after it, which makes it less work to configure. Therefore I started a Rubocop config that we can use as a base for discussion. I tried to add some reasoning to most entries. However let me point out the main choices and deviations from bbatsov here:

  • Line length: 80 is a bit too short to enforce, especially since we have bigger screens these days. I'm working with 120 for years now and so far nobody complained.
  • Different spacing rules for { ... } blocks and hash literals, in order to differentiate them better
  • Using fail requires you to know that it's just an alias for raise with no benefit, in other places the styleguide already discourages using aliases. Having more than one semantic meaning for exceptions is wrong in the first place, it suggests that you're using them for control flow.
  • No safe assignment, that is, do not allow if (foo = bar) while disallowing if foo = bar. We should either allow assignments in if statements or not, this is just inconsistent.
  • Do not enforce block argument names for inject. Enforcing variable names, especially single letter ones is just plain silly.

Additional rules and deviations that I couldn't make out a cop for:

  • Define exceptions as class Foo < RuntimeError; end, not Foo = Class.new(RuntimeError). The later requires more knowledge about Rubys meta model and what the argument to Class.new does for basically no benefit.
  • Disallow spaces inside string interpolation that is allow "a #{b} c" but not "a #{ b } c". This is to settle to one style and keep it consistent.
  • Disallow doing control flow with && and || outside conditionals. The only valid uses of && and || are in a condition and to compute a predicate that's returned from a method.

Please read bbatsov's styleguide and then my Rubocop config if you want to know more.

Javascript

(last edit by Steffen)

The proposed deviations for our settings are: (follow the links for more information about the options)

  • camelcase : true
  • latedef: true
  • maxlen: 120
  • nonew: false. nonew would prohibit the use of constructor functions for side-effects. While testing that setting to me it looked like we need those side-effects for our backbone code. Does anyone have more information about that? (I am no javascript/backbone.js expert)
  • quotmark: 'single'
  • eqeqeq: true
  • freeze: true
  • indent: 2
  • devel: true. We use alert and confirm in some places.
  • eqnull: true.
  • lastsemic: true
  • supernew: true. We use that in some places. I don't know if we should get rid of it but because we are currently using it this is set to true.
  • I also added some global variables we are using.

SCSS

(edited by Pablo Cúbico)

I'm suggesting using the styleguide from Bootstrap, which is a little leaner than things like BEM and OOCSS.

http://codeguide.co/#css

Some ideas from its maker:
http://markdotto.com/2014/07/23/githubs-css/

I'll try to match the configuration of SCSS Lint to it and post it here.

Porting the codebase

We won't do it. As reasoned excellently in Hound's faq, the way to adopt a styleguide is to gradually port all code you write and touch to it, not to do it in one go.

F

Faldrian Sun 22 Feb 2015

120 width is great :)

I don't want assignments in if statements, you rarely need them directly and you could assign the result of the assignment to a variable and then check the variable ... this way the reader can not confuse this easily with the tests in if statements.

For the rest: I have no opinion and trust you do some sane decisions. :)

SVB

Steffen van Bergerem Sun 22 Feb 2015

(changed the description of the discussion, added information about the javascript styleguide)

JH

Jonne Haß Sun 22 Feb 2015

Oh, mh, couldn't everybody edit the start of the discussion at the top?

SVB

Steffen van Bergerem Sun 22 Feb 2015

@jhass done.

A

Augier Sun 22 Feb 2015

About JS camel case, I like the PEP8 i.e : CamelCase for classes or objects or others, snake_case for functions with the minimum length for function name. I don't like the idea of auto-documented code. The actual code (espacially JS) should be systematically documented using /** */ coments.

JH

Jonne Haß Sun 22 Feb 2015

auto-documented code

You mean self-documenting code? If so, any reason? What's wrong with code that's self explanatory? And what's wrong with spending effort on making code clearer than spending that effort on explaining your incomprehensible code instead and making sure the comments stay up-to-date? Do you never experience comment rot?

A

Augier Sun 22 Feb 2015

You mean self-documenting code? If so, any reason? What’s wrong with code that’s self explanatory?

A code is never self-explanatory. It can be comprehensible by someone with sufficient knowledges in a particular language when it's well-written, but that is not self-explanatory, that is just good programming.

But when someone not really comfortable with a language reads it, a code is not self explanatory. This is why we always continue to write documentations...

And what’s wrong with spending effort on making code clearer than spending that effort on explaining your incomprehensible code instead and making sure the comments stay up-to-date?

Can't we do bot ?

Do you never experience comment rot?

Not more than I experience code rot.

JH

Jonne Haß Sun 22 Feb 2015

But our code is not to teach you the language, we're writing a software here, not a book that explains the language or a sample application for someone learning the language.

Not more than I experience code rot.

Lucky you then! I can't say that's my experience, in fact I've seen a lot in diaspora itself.

F

Faldrian Sun 22 Feb 2015

Make comments when necessary, documenting things that may be solved differently and explain why it was done this way.

I think these styleguides set the "must have" part - everyone should still feel free to add a comment to newly written code if it is necessary but not demanding comments when they are not needed.
More important: If you change something, validate that comments are still accurate, so no one reads comments and thinks "okay, I understood what this does" - but the code was changed in between and does something completely different now.

A

Augier Sun 22 Feb 2015

But our code is not to teach you the language, we’re writing a software here, not a book that explains the language or a sample application for someone learning the language.

Common, you know as well as me that it's not about the language. See, even Java devs who I don't think they are bad document their code a lot.

I'm with @faldrian here :

Make comments when necessary, documenting things that may be solved differently and explain why it was done this way.

We all know that diaspora* is not documentaed enough and new devs will never come if this is so difficult to understand the code structure. There are sometimes legacy things that appear to be crazy, espacially in the JS code. Don't forget that we don't code for us, but for those that will come after us.

Lucky you then! I can’t say that’s my experience, in fact I’ve seen a lot in diaspora itself.

There should be a right balance. At leat every JS function should be documented with /** */ comments and two or three lines. Just see JSXC source. It is highly commented and thanks to this easy to modify and maintain.

I think, from now, at least every new JS contribution has to be commented.

JH

Jonne Haß Sun 22 Feb 2015

In both of your examples I see 40-60% of the comments as superfluous. I mean things like /** Some constants */? Or /** My bar id */, bid: null,, here the time would've been better spend by using a self-explanatory name, like bar_id. Most of the comments of your Java example are for the API docs, not to explain the actual code or even the classes structure.

I think, from now, at least every new JS contribution has to be commented.

Java styleguides often have such a requirement, and I know enough developers who don't like it. Therefore I highly disagree with such a requirement. Giving an overview at the top of your class / file about its purpose can be good if it's non-obvious, but it should be applied as necessary, not as necessity. The later only leads to superfluous noise in the code, like in the examples I pointed out (which I didn't even have to scroll down a page for).

A

Augier Mon 23 Feb 2015

In both of your examples I see 40-60% of the comments as superfluous.

That's what I say : you see. But you don't code for yourself, you code for every other developer of diaspora*.

A code is never self-explanatory. It might be for you, but I'm sorry to say that, given a complex function, a name with two or three words is never enough. Especially in JS.

and I know enough developers who don’t like it

Oh ! This is an actual study from the institute of the wet finger !?

At work, I'm responsible for the documentation of all the projects. I see every day devs who were convinced their code was self-documented, no need for comments or actual document. And see, 5 years later, they are unable to say what their code do, what they did it for. For some project, we are even unable to say what they are used for and if they are stil up-to-date ! Documentation and comments are not luxury.

Giving an overview at the top of your class / file about its purpose can be good if it’s non-obvious

Who determines it is non-obvious ? We have to be clear : wether we do, wether we don't. Where you see superfluous comments, I see a sane way of coding where comment helps to see the logic and the structure of the code.

F

Faldrian Mon 23 Feb 2015

When you want to know how something specific works, you will always read the code.

But what we really would need (and I think this is more important than inline-comments or class-comments) is a top-down overview of the whole project, maybe with 2-3 different zoom-levels, explaining how everything works together (graphically with annotations). That would not be part of this styleguide-thing, but a new piece of works.

@augier I don't think we have to introduce mandatory comments here. If you think they are useful and want to add some - you can, but you don't have to.

JH

Jonne Haß Mon 23 Feb 2015

I guess we have to put that point to vote then, let me answer to one more of your points though:

given a complex function, a name with two or three words is never enough.

The problem in that case is not that you have no comment on it, the problem is that you didn't break up your function. I only have a Ruby example at hand, but let's take it. This method calls a bunch of other methods that aren't used anywhere else, they're extracted not for reusability but for readability and to reduce the size of the method.

I can recommend this book, it has an excellent chapter on comments too.

A

Augier Mon 23 Feb 2015

But what we really would need (and I think this is more important than inline-comments or class-comments) is a top-down overview of the whole project, maybe with 2-3 different zoom-levels, explaining how everything works together (graphically with annotations). That would not be part of this styleguide-thing, but a new piece of works.

Agree.

@faldrian : I don't have strong opinion about Ruby, but concerning JS, and given how this language is unnecessarily verbose, I really think we should have document comments for each function more than 4 lines. And there is a lot of them.

The problem in that case is not that you have no comment on it, the problem is that you didn’t break up your function.

This is also a problem, for sure. The there are many complex function of that kind in the JS part. And we all know that they will never be refactored.

Your Ruby example is not fully relevant as Ruby is a very concise and easy to read, which is not the case of JS.
Please also notice that it has many doc comments and is not as difficult to read as you say.

Also, I think we should do an inventory of the SCSS files during the port to BS3.

F

Faldrian Mon 23 Feb 2015

as Ruby is a very concise and easy to read, which is not the case of JS.

I think your milage may vary. I find ruby very disturbing to read and feel like in wonderland when I can read JS. So this does not depend on the language.

JH

Jonne Haß Mon 23 Feb 2015

Also the comment in my example is for the API docs, the extracted private API has no comments at all.

A

Augier Mon 23 Feb 2015

About quotmark, I've adopted the styleguide of Ruby mine for both JS and Ruby, i.e : ' ' by default and " " only when necessary.

JH

Jonne Haß Mon 23 Feb 2015

In Ruby, I found myself repeatedly changing 's to "s since I wanted to use string interpolation or have an interpreted \n and so on, therefore I adopted to default to "s and only use ' if I need to their semantics. Any such reason for preferring ' in JS?

F

Faldrian Mon 23 Feb 2015

Of course! :D https://twitter.com/mathias/status/247708186696634368

(No, there is not even a performance difference ... http://jsperf.com/single-quote-vs-double-quote/3 )

A

Augier Mon 23 Feb 2015

Any such reason for preferring ' in JS?

None, it is just personnal preference. And I prefer using " " for class or id when I define inline HTML, so this prevent quotes collision and usage of \".

Edit : yeah, just like @faldrian :p

Also, about JS, I like JSON rather that function() for object definitions :

JSON :

var object = {
    var1: 'var',
    var2: 'var also'
}

Function definition :

var object = function(){
    var1 = 'var';
    var2 = 'var also;
}

Prettier and easier to read.

A

Augier Tue 24 Feb 2015

Would be nice to set option multistr to true, Milou bothers me with that >.<

SVB

Steffen van Bergerem Tue 24 Feb 2015

The JSHint docs say

Multi-line strings can be dangerous in JavaScript because all hell breaks loose if you accidentally put a whitespace in between the escape character () and a new line.

A

Augier Tue 24 Feb 2015

I didn't know that. Can't wait for ES6...

JH

Jonne Haß Thu 26 Feb 2015

So, shall we put mandatory comments to a vote?

F

Faldrian Thu 26 Feb 2015

Since we exchanged arguments with pretty much no effect, this might be a good idea.

A

Augier Thu 26 Feb 2015

I think so.

To me, proposition should at least include these elements :

  • mandatory comments required for eavery PR
  • at least for JS code
  • at least for functions that are above 3 lines.
JH

Jonne Haß Thu 26 Feb 2015

mandatory comments required for eavery PR
at least for functions that are above 3 lines.

That's contradictory, please clarify.

at least for JS code

All or nothing, doing it for part of the code base and for another part not is just worse.

A

Augier Thu 26 Feb 2015

I say at least, now if we vote fore mandatory comments and you think it's better to

That’s contradictory, please clarify.

Every new function has to be documented unless it is obvious (less than 3 instructions) eg. this is obvious and this too.

I consider as an instruction any call of method. So, if there's chained methods call, each call is an instruction. Eg :

var.call1().call2().call3().call4()

is 4 instructions. But I'd like to limit a too big number of chained call (not more than 4, maybe ?) if possible.

Also, about SCSS is nesting limit relevant ?

JH

Jonne Haß Thu 26 Feb 2015

That's way too vague, you can't measure complexity in LoC or calls.

A

Augier Thu 26 Feb 2015

It's just a proposition, I don't see any other easy way to measure it. It's not useful to put mandatory comments for very obvious case, but we need a clear rule to determine what is ovious and what is not.

F

Faldrian Thu 26 Feb 2015

I don't like rules and hard limits where none are necessary. It is already possible to look through new pull requests and add comments like "hm... big block of code, care to comment some of that?" - if the developer not already has done so.
We all want to write good and understandable code - if there are people who have hints how to make code better understandable, they can say so in the PRs.

I think the solution to documentation issues will more likely be solved by communication and external documentation than by enforcing arbitrary rules on the structure of new code.

Let's focus more on gettings things done here than setting up a ruleset to play by... (that won't be used if people don't see the purpose of it).

JH

Jonne Haß Fri 27 Feb 2015

I'm totally with Faldrian. Since there obviously are no simple rules to determine when a mandatory comment should be placed, do you still hold to wanting them?

A

Augier Fri 27 Feb 2015

We have to find how to better document the code. This is the solution I found. If I'm the only one on this, of course it will never be accepted.

But the problem is still here : the code is still abstruse. So, no matter what, we need a solution on this.

A

Augier Fri 27 Feb 2015

When the styleguide is set, what if I set up a RubyMine inspection file for the official repo ?

JH

Jonne Haß Fri 27 Feb 2015

But the problem is still here : the code is still abstruse. So, no matter what, we need a solution on this.

The way forward is to make it less abstruse, not to bury the clear parts in comments.

When the styleguide is set, what if I set up a RubyMine inspection file for the official repo ?

I don't use RubyMine, so maybe. We will most likely add the above mentioned linters with configs that match the styleguide as good as possible and enable Hound.

A

Augier Fri 27 Feb 2015

I don’t use RubyMine, so maybe. We will most likely add the above mentioned linters with configs that match the styleguide as good as possible and enable Hound.

BTW, RM supports JSHinter and JSLinter.

DU

Dumitru Ursu Tue 3 Mar 2015

JSLint is a bunch of cr*p. It's too harsh for any sane person. JSHint is the way to go, I guess. I think comments should be optional, but each file should at least have a comment, explaining what it's trying to do in the system, why it's needed there. But this can be enforced when accepting PR's, there's no need for a linter to check it.

Regarding SCSS - It's a mess right now. I've been thinking a lot about it, and it's a difficult problem.

I propose to use the SMACSS approach and use these rules to separate the selectors:
https://smacss.com/book/categorizing

We should have 5 folders and a file:

  • base

    • _base.scss (only for including this folder files)
    • random .scss files
  • layout

    • _layout.scss
    • the same rules as before
  • module

  • state

  • themes

    • default (a folder)
    • _main.scss (to include the other files) (this should be nested under default folder, it's something weird with loomio markdown)
    • whatever files the theme creator wanted, it may again follow the SMACSS structure
  • application.scss

    @import 'base/base', 'layout/layout', 'module/module', 'state/state';
    @import 'themes/cerulean/_main'; (changed the theme to cerulean)

SVB

Steffen van Bergerem Tue 3 Mar 2015

@dumitruursu We already use JSHint.

JH

Jonne Haß Thu 5 Mar 2015

Since there's no discussion around it, I will start the vote for the Ruby styleguide tomorrow, unless discussion emerges until then.

JH

Jonne Haß started a proposal Fri 6 Mar 2015

Ruby styleguide Closed Mon 16 Mar 2015

Outcome
by Jonne Haß Tue 25 Apr 2017

The proposal passed.

Adopt bbatsovs styleguide with the derivations enforced by this Rubocop config and the additional derivations mentioned in the description of this discussion.

Results
Agree - 4
Abstain - 4
Disagree - 4
Block - 4
7 people have voted (12%)
JH

Jonne Haß
Agree
Fri 6 Mar 2015

A

Augier
Agree
Fri 6 Mar 2015

In @jhass, I trust.

A

aj
Abstain
Fri 6 Mar 2015

DU

Dumitru Ursu
Agree
Fri 6 Mar 2015

I would still like to have "fail" when the intention is to terminate the program and "raise" when you re-raise an exception, but I do not insist on it.

JH

Jonne Haß Sat 7 Mar 2015

@dumitruursu I recently found Kernel#abort, which is the official way to abort the program with an error state.

DU

Dumitru Ursu Sat 7 Mar 2015

hmm, that is actually not bad.

FS

Florian Staudacher
Agree
Sat 7 Mar 2015

looks good to me ;)

JR

Jason Robinson
Abstain
Sat 7 Mar 2015

Happy for those who care about ruby to decide ;)

SVB

Steffen van Bergerem Tue 10 Mar 2015

In the proposed settings for jshint I changed
camelcase : true: we already use camelcase for most backbone.js functions
quotmark: 'single': no need to escape double quotes in HTML
maxlen: 120

I will create a proposal for the javascript styleguide as soon as the ruby proposal closes.

A

Augier Wed 11 Mar 2015

So there's no possibility to differentiate camelCase for class names and function and snake_case for local variables ? Well. I'll deal with it.

F

Flaburgan
Abstain
Wed 11 Mar 2015

SVB

Steffen van Bergerem started a proposal Tue 17 Mar 2015

Javascript Styleguide Closed Fri 27 Mar 2015

Outcome
by Steffen van Bergerem Tue 25 Apr 2017

The proposal passed.

Enforce the javascript styleguide as described in the discussion and implemented by the following JSHint config: https://gist.github.com/svbergerem/83f5d267cc1897d64edd

Results
Agree - 7
Abstain - 7
Disagree - 7
Block - 7
9 people have voted (16%)
DS

Dennis Schubert
Agree
Tue 17 Mar 2015

I usually tend to using double quotes, but it looks good to me.

JH

Jonne Haß
Abstain
Tue 17 Mar 2015

No JS expert, but seems solid.

A

Augier
Agree
Tue 17 Mar 2015

Ok to me.

A

Augier Tue 17 Mar 2015

In addition, I'd propose to use JS Code Style to enforce some rules like no trailing spaces.

SVB

Steffen van Bergerem
Agree
Tue 17 Mar 2015

DL

Dani'el Levity
Agree
Tue 17 Mar 2015

Makes life easy..

DS

Dennis Schubert Tue 17 Mar 2015

In addition, I’d propose to use JS Code Style to enforce some rules like no trailing spaces.

It is absolutely unnecessary to use two tools doing basically the same. JSHint does everything we need. Trailing whitespace should be removed anyway, but that's nothing JS specific. ;)

F

Faldrian
Agree
Tue 17 Mar 2015

SVB

Steffen van Bergerem Tue 17 Mar 2015

In addition, I’d propose to use JS Code Style to enforce some rules like no trailing spaces.

I agree. The JSHint docs say that some options will be removed in the next major release and that you should use JSCS for those instead. Unfortunately Hound doesn't support JSCS yet and as far as I know there is no Ruby gem for JSCS.

A

Augier Tue 17 Mar 2015

@dennisschubert : as @steffenvanbergerem said, the options related to code style are going to be deprecated in the next release of JSHint. They say that JSHint is only about code correctness and not code style. JS has a lot of ways to do some things and I saw very different ways of developing while working on the notifications system. We need to agree on things like using var that = this; or rather var self = this;, spaces usage (before and/or after brackets and curly braces?) and so on. Every big project has a code style. It improve the understandability of the code as it provides conventions.

JR

Jason Robinson
Agree
Tue 17 Mar 2015

I really think double quotes are a saner choise for javascript - but won't fight for that.

SVB

Steffen van Bergerem Tue 17 Mar 2015

@dennisschubert @jasonrobinson If you want we can have another proposal after the current one to decide whether we prefer single or double quotes. In that case I would keep the current value (false, accept single and double quotes) until we have an outcome for the second proposal.

It would be a bad idea to enforce single quotes if the majority prefers double quotes.

F

Flaburgan
Abstain
Thu 26 Mar 2015

K

ktf
Agree
Fri 27 Mar 2015

SVB

Steffen van Bergerem started a proposal Sat 28 Mar 2015

Javascript Styleguide: Use double quotes Closed Tue 31 Mar 2015

Outcome
by Steffen van Bergerem Tue 25 Apr 2017

We will use double quotes.

Change the approved javascript styleguide by using double quotes instead of single quotes.

Results
Agree - 3
Abstain - 3
Disagree - 3
Block - 3
4 people have voted (7%)
JH

Jonne Haß
Agree
Sat 28 Mar 2015

Encourages templating and is consistent with the Ruby styleguide.

A

Augier
Disagree
Sat 28 Mar 2015

It forces either to use single quotes in HTML, either to escape double quotes. Decreases readabilty.

JR

Jason Robinson
Agree
Sun 29 Mar 2015

Yes please, double quotes are so much nicer. I'd prefer not having to use either, but if one is needed to be chosen, double it should be :)

SVB

Steffen van Bergerem
Agree
Mon 30 Mar 2015

PC

Pablo Cúbico Sun 5 Apr 2015

For (S)CSS I suggest adopting the coding styles from Bootstrap, which are very reasonable, and will provide enough structure to make the code consistent.

Also, it will be very useful to have a similar notation on the bootstrap styles and our own, with no modular__classNaming--nonsense.

http://codeguide.co/#css

I think it will be pretty easy to adopt too.

This is only for the "measurable" styleguide, there are also some best practices we should adopt, but those will be our own, and we can add best practices gradually on the run as we find use cases. I have a few of my own to suggest.

@steffenvanbergerem if you guys want me to create a separate proposal, just let me know. I see this one is closed, but I guess the discussion is still alive.

JH

Jonne Haß Sun 5 Apr 2015

A discussion can totally have multiple proposals, we already used this one to decide Ruby and Javascript. Feel free to edit the top post accordingly too to reflect current discussion status.

I'd like to enforce the styleguide with HoundCI, at least as much of it as possible. It runs SCSS-Lint, do you happen to run across an existing config for the guide you propose?

PC

Pablo Cúbico Sun 5 Apr 2015

Nope, but I'll give it a try.

There are some further insights on the approach that gave birth to that styleguide here, the guys at Github use SCSS and the linter too:

http://markdotto.com/2014/07/23/githubs-css/#linting

PC

Pablo Cúbico Tue 7 Apr 2015

I still have to check some config values to see if they are fully compatible with the guide I posted, but for anyone interested in taking a look, here is the ANSI-colored output of SCSS Lint with Hound's config, which I think is pretty close to the guide:

http://www.vispress.com/scss-lint-hound.txt

And here are the differences between the default scss-lint config and Hound's:

https://www.diffchecker.com/n2wj07ys

I think maybe we should disable some rules, or apply some automatic styling, even using sed...

A

Augier Sun 7 Jun 2015

As I pointed it here one of the things that gave me hard time whil porting to BS3 was the fact that classes where used both to define CSS rules and to select in JS.

As most of the CSS rules defined could be removed because they were alreay defined by BS, I nerver knew if the class ws safe to remove or if it was still used by any JS somewhere.

So, my idea would be, from now, to avoid using the same classes to define CSS rules and to select in JS. The diference could be pointed by the use of a prefix on the classes used by JS like js-. This will avoid to break logic or unit tests in the future when removing deprecated classes.

SVB

Steffen van Bergerem Sat 29 Aug 2015

For SCSS I think we could start with the default config of scss-lint. Any comments before I create a new proposal?

SVB

Steffen van Bergerem started a proposal Thu 3 Sep 2015

SCSS Styleguide Closed Thu 10 Sep 2015

Outcome
by Steffen van Bergerem Tue 25 Apr 2017

We will use scss-lint with the default config.

Results
Agree - 6
Abstain - 6
Disagree - 6
Block - 6
6 people have voted (10%)
F

Faldrian
Agree
Thu 3 Sep 2015

JR

Jason Robinson
Agree
Thu 3 Sep 2015

JH

Jonne Haß
Agree
Thu 3 Sep 2015

A

Augier
Agree
Thu 3 Sep 2015

SVB

Steffen van Bergerem
Agree
Thu 10 Sep 2015

F

Flaburgan
Agree
Thu 10 Sep 2015

A

Augier Mon 26 Oct 2015

Does someone knows a JSLinter to enforce some programmatic rules like do not use parseInt without base or do not use for(... in ...) loop?

I've discovered here that parseInt was used without giving a base, for instance.

F

Flaburgan Sun 22 Nov 2015

Hey, I'd like to discuss about the two rules:
- to not use ids selector
- to not have a depth of 4 or more

I know ids selector are bad for performance, but I'm not sure that we need to be that strict about it.
And I would like to know why it's bad to have a big depth? Scss is compiled anyway, I'm not sure why we want to avoid that, it's even useful to avoid side effect.

A

Augier Sun 22 Nov 2015

And I would like to know why it’s bad to have a big depth? Scss is compiled anyway, I’m not sure why we want to avoid that, it’s even useful to avoid side effect.

As Steffen indicated me tonight, the given reason is that deep depth lead to a CSS tightly-coupled to your HTML structure.

Though, I tend to agree with you: I think the depth could be extended to 5.

Same about ID selectors. IMHO, there are legit use case.

SVB

Steffen van Bergerem Sun 22 Nov 2015

You can find reasons for these rules in the scss-lint documentation.

IdSelector
SelectorDepth