regarding RequireJS parameter Upper or Lower camel case naming convention
I think parameter should start with upper/lower case letter based on the way it is used, e.g. if it is used as a constructor, than it would be capital letter, otherwise - small letter.
You mean for "RequireJS parameter Upper or Lower camel case naming convention".? I think the RequireJS define/require function call is a different scenario that needs to be handled differently... let me explain.
RequireJS with LOWER camel case
define("app", ["AppModel"], function(appModel) {
console.log(appModel.text); // Accessing like a static, looks kind of odd
var model = new appModel(); // JSLint will not allow this. "A constructor name 'appModel' should start with an uppercase letter."
}
RequireJS with UPPER camel case
define("app", ["AppModel"], function(AppModel) {
console.log(AppModel.text); // Accessing like a static, looks good now
var model = new AppModel(); // JSLint will be happy, looks as you'd expect it
}
In the RequireJS define function I think it makes sense to always use upper camel case. In everyday functions I think it should always be lower camel case, but can be more complicated...
Everyday function
function(appModel, myString, uiUtils) { // This is confusing...
uiUtils.someStaticLikeFunction(appModel, myString); // ...and now looks weird/wrong
}
But I think this should never really happen anyway as this is how it would be structured in reality
define(['utils', 'Car'], function (utils, Car) {
var something = utils.getSomething(); // small letter
var bmw = new Car(); // capital letter
});
those 2 dependencies are used in different ways, so there is not just that all letters are small or capital ones.
Also why do you the following is weird?
uiUtils.someStaticLikeFunction(appModel, myString); // ...and now looks weird/wrong
I would not call this static: uiUtils is an object which simply holds various properties. Static variable/function is a variable shared by all instances of a "class".
I guess I'm viewing this from a point of view of consistency.
Take this scenario...
define("app", ["Car"], function(car) {
var carType = car.SPORTS;
}
I know that car is actually an object with various attributes but you access it like a static like you would Math.PI so in my mind it looks kinda weird using lower camel case.
Now suppose I now change the above bit of code to...
define("app", ["Car"], function(Car) {
var carType = Car.SPORTS;
var car = new Car(carType)
}
I've been force to change to an upper camel case Car as the linter will fail otherwise. I can now also use var car which I couldn't do before without conflicting with the passed in car.
In my mind the second has clearer intent and will end up being the final form if I ever want to use the new keyword.
I take your point about changing the case depending on how it's being used. I guess the trade-off is:
Changing case on the usage: Means you can tell the usage from the case, but not where it came from (internal var or RequireJS)
Changing case if it's RequireJS or not: Means you can tell from the case if it's a external dependency, but the case no longer tells you the usage
How the identifier is used vs where the identifier came from
Same, I agree with most of this points. Maybe make it recommended reading ( ? ) but also pick out some of suggested rules he list, e.g. "Don’t allow IDs in your selectors" and integrate that into the guide.
Thinking of that, we might what to split this page down into JS, CSS and HTML subpages
8 Comments
Unknown User (esergueeva)
regarding RequireJS parameter Upper or Lower camel case naming convention
I think parameter should start with upper/lower case letter based on the way it is used, e.g. if it is used as a constructor, than it would be capital letter, otherwise - small letter.
Unknown User (phil.ostler)
You mean for "RequireJS parameter Upper or Lower camel case naming convention".? I think the RequireJS
define/require
function call is a different scenario that needs to be handled differently... let me explain.In the RequireJS
define
function I think it makes sense to always use upper camel case. In everyday functions I think it should always be lower camel case, but can be more complicated...But I think this should never really happen anyway as this is how it would be structured in reality
What do you think?
Unknown User (esergueeva)
What I was thinking is this:
those 2 dependencies are used in different ways, so there is not just that all letters are small or capital ones.
Also why do you the following is weird?
I would not call this static: uiUtils is an object which simply holds various properties. Static variable/function is a variable shared by all instances of a "class".
Unknown User (phil.ostler)
Correct on your first point, copy paste #fail
I guess I'm viewing this from a point of view of consistency.
Take this scenario...
I know that car is actually an object with various attributes but you access it like a static like you would
Math.PI
so in my mind it looks kinda weird using lower camel case.Now suppose I now change the above bit of code to...
I've been force to change to an upper camel case
Car
as the linter will fail otherwise. I can now also usevar car
which I couldn't do before without conflicting with the passed incar
.In my mind the second has clearer intent and will end up being the final form if I ever want to use the
new
keyword.I take your point about changing the case depending on how it's being used. I guess the trade-off is:
How the identifier is used vs where the identifier came from
Unknown User (esergueeva)
Existing style guides:
JS
http://addyosmani.com/blog/javascript-style-guides-and-beautifiers/ (list of style guides inside)
https://github.com/airbnb/javascript
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#JavaScript_practices
HTML / CSS
https://css-tricks.com/css-style-guides/ (list of style guides inside)
___
http://philipwalton.com/articles/css-architecture/ I like some of the principles here, can we integrate it somehow into the guide?
Unknown User (phil.ostler)
That pretty much covers everything
Unknown User (phil.ostler)
Same, I agree with most of this points. Maybe make it recommended reading ( ? ) but also pick out some of suggested rules he list, e.g. "Don’t allow IDs in your selectors" and integrate that into the guide.
Thinking of that, we might what to split this page down into JS, CSS and HTML subpages
Unknown User (esergueeva)
I will put it here, so won't lose it:
1) Modules
naming: openam-XXX
examples: openam-ui-scripts, openam-ui-ria, etc.
2) Folders
naming: Use single descriptive word. Use plural form for folders which contain groups of similar items, e.g. "models"
examples: models, views, collections, delegates, etc.
3) JavaScript Files
naming: UpperCamelCase.js
examples:
a) XxxView.js, XxxModel.js, XxxCollection.js, XxxDelegate.js, XxxUtils.js, etc.
b) main require.js file: main.js
4) Css Files
naming: single descriptive word (lowercase)
examples:
a) dashboard.less, uma.less, etc.
b) main css file: styles.less
5) Html Files
naming: UpperCamelCase.html
examples:
a) XxxTemplate.html, etc.
b) index.html
6) Json Files - keeping them consistent with javascript files
naming: UpperCamlCase.json
example: ThisThing.json