Generally we encourage inline comments. These help readers of your code to understand the logic without having to understand every line of code. It's also a good practice to write inline comments before you write code so that you first think about the logic and semantics you want to implement and then about the syntax.

Generally we encourage inline comments. These help readers of your code to understand the logic without having to understand every line of code. It's also a good practice to write inline comments before you write code so that you first think about the logic and semantics you want to implement and then about the syntax.

−

= Visibility =

+

= Object Oriented Programming in JS =

−

We use the @constructor, @protected and @private markers that Google recommends and Eclipse understands.

+

== Inheritance ==

−

We group members by visibility and class (static) vs. object (instance) membership:

+

There are many ways to implement inheritance in JavaScript. We chose our approach for flexibility, simplicity and memory/execution performance.

−

* private static class variables (start with underscore)

+

−

* private instance variabes (start with underscore)

+

−

* protected instance variables (discouraged)

+

−

* public static class variables or instance variables are not allowed!

+

−

* public static methods

+

−

* public methods

+

−

* protected static methods

+

−

* protected methods

+

−

* private static methods (start with underscore)

+

−

* private methods (start with underscore)

+

−

Sections are divided with a three line // style comment indicating the class member category.

+

We are using a (pseudo-)classical approach of inheritance rather than the purely prototypical or mixin approach:

* It's easier to put in an intermediate object above the parent when we use constructors from the beginning.

+

* It's easy to insert initialization code in the parent object if required at a later stage because we won't have to insert <code>new</code> everywhere in the code.

+

* There's minimal overhead in using functions as parents if we make sure to not call the constructor (thereby avoiding potential side effects of the constructor and making a potentially big object) when letting a child inherit from the parent, see use of 'Temp' above.

−

Protected class members are named like public methods but they must not be used outside of the inheritance hierarchy of the current class.

Sections are divided with a three line <code>//</code> style comment indicating the class member category.

+

+

You are obviously not supposed to use a member outside its scope even if the visibility is not enforced by closure. Please run <code>lib/pkp/tools/buildjs.sh</code> on your code to make sure that you have not overlooked anything. This is also true for protected object members. While they are named like public methods they must not be used outside of the inheritance hierarchy of the current class.

Google Coding Conventions

JsDoc Comments

We use JsDoc comments as outlined in the Google style guide with but we name the variable name directly after the @param tag and the type without curly braces.

Generally we encourage inline comments. These help readers of your code to understand the logic without having to understand every line of code. It's also a good practice to write inline comments before you write code so that you first think about the logic and semantics you want to implement and then about the syntax.

Object Oriented Programming in JS

Inheritance

There are many ways to implement inheritance in JavaScript. We chose our approach for flexibility, simplicity and memory/execution performance.

We are using a (pseudo-)classical approach of inheritance rather than the purely prototypical or mixin approach:

It's easier to put in an intermediate object above the parent when we use constructors from the beginning.

It's easy to insert initialization code in the parent object if required at a later stage because we won't have to insert new everywhere in the code.

There's minimal overhead in using functions as parents if we make sure to not call the constructor (thereby avoiding potential side effects of the constructor and making a potentially big object) when letting a child inherit from the parent, see use of 'Temp' above.

Sections are divided with a three line // style comment indicating the class member category.

You are obviously not supposed to use a member outside its scope even if the visibility is not enforced by closure. Please run lib/pkp/tools/buildjs.sh on your code to make sure that you have not overlooked anything. This is also true for protected object members. While they are named like public methods they must not be used outside of the inheritance hierarchy of the current class.