7 ms·

> If you’re the first person on the project, use camelCase; it’s easier to select camelCased text in an IDE than it is hyphenated text Doesn't this go against

> If you’re the first person on the project, use camelCase; it’s easier to select camelCased text in an IDE than it is hyphenated text Doesn't this go against the conventions of the most popular CSS libraries that your code will likely be used with? It's a pain and ugly that JavaScript and CSS don't use the same conventions though. The IDE select issue is probably fixable e.g. https://stackoverflow.com/questions/45590695/visual-studio-select-word-with-hyphen https://stackoverflow.com/questions/45590695/visual-studio-s...

stickfigure 5y ago
Another advantage of camelCase is that classNames (https://github.com/JedWatson/classnames https://github.com/JedWatson/classnames) works without quoting: // you have a variable isFoo <SomeComponent className={classNames({isFoo})} /> is a lot better than: // you have a variable isFoo <SomeComponent className={classNames({'is-foo': isFoo})} /> (also, I personally shorten `classNames` to `cn` because it's so universally useful)
- seanwilson 5y ago
  Yep, it would be nice if HTML/XML/CSS/Javascript/YAML/JSON/SQL identifiers were all standardised as it's not uncommon to see all of them in the same project.
paceaux 5y ago
So, worth explaining (as I've told other folks here), my experience is in enterprise content management, usually building good ol' fashioned websites that are running on .net and getting content from a CMS. For the entirety of my career, I never ONCE worked with a CSS library. Every single one of my clients (who were on the Fortune 500 list, usually) had too unique of a design and too many different types of pages for us to bring in an external CSS library. So, for that reason, when I wrote these guidelines internally some years ago, we weren't concerned in the least with what CSS libraries were doing because we didn't use them. We were concerned with consistency, more than anything We went with camelCase because we liked that it was the same convention we followed in our JavaScript, AND it was easy to select stuff in the IDE. Even WITH there being a VSCode extension, I still wouldn't change my reasoning because that kinda breaks the guidance of, "least disruptive to the team." I wouldn't want to have a project that required some IDE extension to keep teammates productive the way they want. ALL THAT SAID, as I explained in the start of the guidelines, they are just that...guidelines. The goal is to be consistent and not have teammates present or future curse your name. So developers should really favor team cohesiveness over my opinions based on my specific experience.

stickfigure 5y ago

Another advantage of camelCase is that classNames (https://github.com/JedWatson/classnames https://github.com/JedWatson/classnames) works without quoting: // you have a variable isFoo <SomeComponent className={classNames({isFoo})} /> is a lot better than: // you have a variable isFoo <SomeComponent className={classNames({'is-foo': isFoo})} /> (also, I personally shorten `classNames` to `cn` because it's so universally useful)

seanwilson 5y ago
Yep, it would be nice if HTML/XML/CSS/Javascript/YAML/JSON/SQL identifiers were all standardised as it's not uncommon to see all of them in the same project.

paceaux 5y ago

So, worth explaining (as I've told other folks here), my experience is in enterprise content management, usually building good ol' fashioned websites that are running on .net and getting content from a CMS. For the entirety of my career, I never ONCE worked with a CSS library. Every single one of my clients (who were on the Fortune 500 list, usually) had too unique of a design and too many different types of pages for us to bring in an external CSS library. So, for that reason, when I wrote these guidelines internally some years ago, we weren't concerned in the least with what CSS libraries were doing because we didn't use them. We were concerned with consistency, more than anything We went with camelCase because we liked that it was the same convention we followed in our JavaScript, AND it was easy to select stuff in the IDE. Even WITH there being a VSCode extension, I still wouldn't change my reasoning because that kinda breaks the guidance of, "least disruptive to the team." I wouldn't want to have a project that required some IDE extension to keep teammates productive the way they want. ALL THAT SAID, as I explained in the start of the guidelines, they are just that...guidelines. The goal is to be consistent and not have teammates present or future curse your name. So developers should really favor team cohesiveness over my opinions based on my specific experience.