3 ms·
I like the human-readability that dashes lend to URLs, but there are two things that bother me about using them in this case: 1. A dash is an operator, which c
by VaughnDTaylor 14y ago
I like the human-readability that dashes lend to URLs, but there are two things that bother me about using them in this case:
1. A dash is an operator, which could get confusing when you are doing math. For example: (@grid-gutter-width * (@grid-columns - 1)).
2. As far as variables go... thisIsDoubleClickable, and_so_is_this, but-this-is-not. I suppose it's not the biggest deal in the world, but I really hate having to drag my mouse to select.
My two cents...
- bung 14y agoYea this is an age old discussion, I also like the separation that dashes or underscores give. Personally I'm a fan of underscores myself, mostly because I can then have id="foo_bar" #foo_bar and $foo_bar, for html, css, and jQuery variables, respectively, and remembering that JS can't have dashes in variable names. This makes the double clickable aspect super handy to me :) Sometimes I hear that people don't want to have to press shift, which is understandable considering how much we code. But if bootstrap devs are already pressing shift in order to use camelCase, I wonder why they didn't pick underscores.
- VaughnDTaylor 14y agoThis is my general rule: If it's client-facing (eg. a URL) then use dashes - it's more readable (at least I feel it is). If it's developer-facing, use underscores or camel case. Sure it's not as pretty, but it's functional - which is really what we need. This boils down to - do whatever is best for the user.