Developer Community
Child pages
  • Web (JS, HTML, CSS)
Skip to end of metadata
Go to start of metadata

  • No labels

8 Comments

  1. 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.

    1. 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.

      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

      Real world everyday function
      define("app", ["UIUtils"], function(UIUtils) {
    return {
        myFunction: function(appModel, myString) {
            UIUtils.someStaticLikeFunction(appModel, myString);
    }
}

      What do you think?

       

      1. Unknown User (esergueeva)

        What I was thinking is this:

        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". 

         

        1. 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...

          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

  2. 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?

     

    1. Unknown User (phil.ostler)

      That pretty much covers everything

    2. 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

  3. 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