Child pages
  • Grouper developers coding standards
Skip to end of metadata
Go to start of metadata

We request that Grouper developers adhere to these standards:

Source control

  • Master is the dev branch.  If a new release was just cut, master might be the current release.  Once work is needed on the next release a branch will be created.  Branch names must follow the convention: GROUPER_2_3_0
  • When committing (pull request or direct commit), you should have one JIRA associated with the commit.  

    GRP-1279: grouper installer should set sql logging to on so we can see progress of DDL on install or upgrade
     
    If there are more commits on the same issue, number them:
     
    GRP-1279: grouper installer should set sql logging to on so we can see progress of DDL on install or upgrade (commit 2)
    GRP-1279: grouper installer should set sql logging to on so we can see progress of DDL on install or upgrade (commit 3)
  • Every commit must have a unique comment (from all other commits).  This is so we can go back and see what hasnt been merged
  • Every commit in a non-master branch that should be merged forward must be cherry picked by the developer into all newer branches including master at the time of the commit
  • Pull requests must be on a recent pull of the branch the request is destined for so there are no conflicts
  • All new/edited junit tests should be included in patches

Java

  • There is are eclipse formatting and prefs files in grouper/misc/eclipse
  • Never use tabs, only 2 spaces
  • Use curlies always e.g. for loops and if statements
  • Try to be explicit in naming classes and variables, try not to abbreviate
    • If a field or variable can be named the same as its type it might make things more clear or easier to read later.
    • e.g. if the type is "GrouperAttestationAttribute", maybe name it "grouperAttestationAttribute" instead of just "attribute"
  • Comment a lot
  • Always have javadoc
  • For new code don't commit if there are warnings in eclipse
  • Generally we use unchecked exceptions
  • Keep things backwards compatible generally, deprecate if needed

UI

  • Try not to use javascript, use the ajax API to write logic in Java and views in JSP


JIRA


See also