Developer Best Practices and Code Review

IdentityIQ (IIQ) IIQ Community Knowledge Base
,
1

Hi All,

In this document I am going to explain bit about Dev best practices while writing the code and Code Review best practices while reviewing code.

  1. Use independent libraries and workflows.

  • The best way to avoid issues introduced into common code changes is to, to the extent possible, instead of introducing your changes directly into a common code source (such as the workflow library or the Rule library), try to create independent code libraries and subprocesses and reference them in common code.

  1. Write code consistent with best practices.

  • Code quality is particularly important because there is a good chance that someone in the future will need to understand it without prior context. Here are some high-level guidelines:
  • Follow standard Java conventions and standards.
  • Use proper indentation.
  • Comment on your code thoroughly
    • A good rule of thumb is to give high-level comments on what each code block is doing and then comment on anything unusual that you do.
  • Write code that is clear and easy to understand.
    • Write your code in a way that is easy to follow logically, and be consistent with the way you are writing it.
  • Keep code performance efficient.
  • Create or update existing documentation wherever appropriate.
  • The code should be reviewed by the team, and they should make sure to keep the proper log statements.

  1. Developer Best Practices and Code Review

  • Use proper naming conventions for all variable declarations.
    Ex: ‘Identity idnRequester’ or ‘int intIdentityCount’.
  • Any connection objects (e.g., database, file, server) need to be closed in the finally block.

Ex:

try{
conn= DriverManager.getConnection(“”);
}
catch(SQLException ex){
handle the exception or throw as general exception
}
finally{
try{
if(conn !=null){
conn.close();
}
}catch(){
}
}

  • While throwing the exception, wrap it with GeneralException along with the information that is causing the exception.

Ex:

catch(){
throw new GeneralException(“occurred while loading the entitlement data”,e);
}

  • Don’t log for throwing the exception in the catch block; it results in duplicate logs in the log file for the same exception.

Ex:

catch(illegalArgumentException e){
//log.error(e); do not do this
throw new GeneralException(“occurred while loading the entitlement data”,e);
}

  • Always check for the null object while accessing any object.

Ex:

Identity id= context.getObjectByName(Identity.class,“test”);
if( null ==id){
log.erro("no identity found);
return ;
}

  • Check for voids if you are accessing out of boxes variables in any rules, workflows, forms, etc.
  • Check for object instances if you are not sure about the run-time object. (instanceof List or instanceof String).
  • Try to avoid logic in workflow steps; call a method from a rule.
  • Try to avoid saving a complete object in the workflow parameter until it is really required.
  • Make sure that while deploying the code in production, the trace parameter is set to false.
  • Practice using a separate logger object for each rule.
    Ex: Logger log= Logger.getLogger(“”);
  • Always use context.search with specific columns while loading data.
  • Avoid using iiq objects as variable names.
  • Flush the iterator once it is done with the logic. This will release the cursor object related to the database.

Ex: Util.flushIterator(itername);

  • Decache the loaded objects once done with the operation.
    Ex: context.decache(obj name);
  • Default imports for bean shell. Do not add imports explicitly.

Ex:

java.net.;
java.lang.;
java.util.*;

  • Do not print passwords in logs; put password generation in before the provisioning rule, and try to implement an encryption mechanism.
  • Do not log any "sailpoint object data.

Ex: log.debug(plan.toXml()), log.debug(project.toXml()).

  • Do not log any authentication token at any level.

  • If you are referring to any rule in your new rule, refer to all the references to the parent rule as well.

  • Push the code from IIQ to Repo with the tokenization process and in CDATA format, which are optional. But it is a good practice to maintain.

  • While we are developing any code, we should keep in mind that the performance issue is important so that the code does not create a performance impact. So, write the script in such a way and keep code performance efficient.

2 Likes