EmaCodingGuidelines

What is Ema? WikiSquatting?

Many of these are fairly bad guidelines to boot. Such as? Many of them are similar to what we use.

• All Objects are exposed as Interface to enforce the "Programming to Interfaces rather than Classes" concept

• Test cases should be written to ensure the services provided by objects can be tested with only the minimal required dependency

• Development follows the pattern of
• Define Interfaces
• Create mock implementation wherever required
• Write test cases
• Package so that it can be used by other developers
• Actual implementation of interface

• Ensure the environment is set up to share the common settings such as the file/code templates in IDEA

• All package names should be in lowercase

• In the set methods of the members, ensure the incoming param is named as new<member>

	e.g. 
	   public class UserImpl implements User {
	     private String userName;
	     :
	     :

	     public String setUserName( String newUserName){
	     	userName = newUserName();
	     }

	     :

	   }

• Do not use "this.<member>" code as the "this." not only makes the code dense also some compilers do not support it.

	e.g. 
	   this.userName = userName;  --> Bad

	   userName = newUserName;    --> Good

• Ensure all classes/members/methods are named clearly

• Provide adequate documentation

• Use formatCode/optimizeImports in IDEA to cleanup code

• Refactoring is different from adding new feature, changing/enhancing existing functionality.

  It provides an opportunity to review your code for better usage.

• Use ToDo tag to identify tasks you need to work on

• Organize the packages such that it is more meaningful and also can be grouped and converted into jars with less effort

• Wrap the conditional statements always

	e.g.

	GOOD
	----
	if ( var1 = value1) {
	  //do something	
	}

	BAD
	---
	if ( var1 = value1) 
	  //do something	

• Class/Interface Names always starts with Uppercase and words separated by camelCase

	e.g.
	Good >>
	    public class TestClassForClassNaming {
	    }

	Bad >>
	    public class Testclassforclassnaming {
	    }

	    public class testClassForClassNaming {
	    }

• Method Names always starts with lowerCase and words separated by camelCase

	e.g.
	Good >>
	    public void testMethodForMethodNaming {
	    }

	Bad >>
	    public class TestMethodForMethodNaming {
	    }

	    public class testmethodformethodnaming {
	    }

• Constant Names are always in UpperCase and words separated by '_'

	e.g.
	Good >>
	    public final String TEST_CONSTANT = "TEST";

	Bad >>
	    public final String testconstant = "TEST";

	    public final String Testconstant = "TEST";

	    public final String TestConstant = "TEST";

• Member Names always start with lowerCase and words separated by camelCase

	e.g.
	Good >>
	    private String testMember;

	Bad >>
	    private String TestMember;

	    private String Testmember;

	    private String testmember;

• When using Singleton get the instance always from an Instance provider such as the com.ema.core.utils.ClassInstance and/or using a Proxy Bean factory

• Use Parentheses to clearly depict the expressions

• Try to avoid multiple return points