Developing an app is easy, but developing while following all the conventions makes the other developers to understand your code easily. Suppose you were developing an application, and left the project, that project is shifted to some other developers. That new developer working on your code will find so much easy to understand your code if you follow all the below coding conventions.
——–>1. Naming Convention : Use full English descriptors that accurately describe the variable/field/class/interface. For example, use names like firstName, grandTotal, or CorporateCustomer.
Use terminology applicable to the domain. If the users of the system refer to their clients as Customer, then use the term Customer for the class, not client. Use mixed case to make names readable. For example, to use a short form for the word “number”, choose one of nbr, no or num. Avoid long names (<15 characters is a good tradeoff), and Avoid names that are similar or differ only in case.
——–>2. Standards for Member Functions : Member functions should be named using a full English description, using mixed case with the first letter of any non-initial word capitalized. The first word of the member function should be a verb. Example :-openAccount(), printMailingList(), save().
——–>3. Naming Accessor Member Functions :
Getters: member functions that return the value of a field/ attribute/property of an object. Use prefix “get” to the name of the field/attribute/property if the field in not boolean. Use prefix “is” to the name of the field/attribute/property if the field is Boolean. A viable alternative is to use the prefix ‘has’ or ‘can’ instead of ‘is’ for boolean get.
Examples : getFirstName(), isPersistent()
Setters: member functions that modify the values of a field. Use prefix ‘set’ to the name of the field.
——–>4. Comments should add to the clarity of code : Constructors: Member functions that perform any necessary initialization when an object is created. Constructors are always given the same name as their class. For Examples
——–>5. Member Function Visibility : A good design requires minimum coupling between the classes. The general rule is to be as restrictive as possible when setting the visibility of a member function. If member function doesn’t have to be public then make it protected, and if it doesn’t have to be protected than make it private.
——–>6. Use single-line comments for business logic.
——–>7. Naming Constants : In Java, constants, values that do not change, are typically implemented as static final fields of classes. The convention is to use full English words, all in upper case, with underscores between the words. For Example, MINIMUM_BALANCE, MAX_VALUE, DEFAULT_START_DATE
——–>8. Field Visibility : Fields should not be declared public for reasons of encapsulation. All fields should be declared private and accessor methods should be used to access / modify the field value. This results in less coupling between classes as the protected / public / package access of field can result in direct access of the field from other classes Visibility decisions If a field is declared anything but private then it should be documented why it has not been declared private.
——–>9. Declaring and Documenting Local Variables : Declare one local variable per line of code Document local variable with an endline comment. Declare local variables immediately before their use
Use local variable for one operation only. Whenever a local variable is used for more than one reason it difficult to understand. It also increases the chances of introducing bugs into the code from unexpected side effects of previous values of a local variable from earlier in the code.
——–>10. Reusing local variables is more efficient because less memory needs to be allocated, but reusing local variables decreases the maintainability of code and makes it more fragile.
——–>11. Naming Parameters : Parameters should be named following the exact same conventions as for local variable. Name parameters the same as their corresponding fields.
Example:- If Account has an attribute called balance and you needed to pass a parameter representing a new value for it the parameter would be called balance The field would be referred to as this.balance in the code and the parameter would be referred as balance.
——–>12. Naming classes : Use full English descriptor starting with the first letter capitalized using mixed case for the rest of the name.
——–>13. Line Length : Avoid lines longer than 80 characters, since they’re not handled well by many terminals and tools.
——–>14. Switch Statements : Every switch statement should include a default case. The break in the default case is redundant, but it prevents a fall-through error if later another case is added.