Skip to end of metadata
Go to start of metadata


  • Names should be clear, concise and purposeful.  
  • Take the time to name things in a way that's self-documenting; don't settle for the quickest idea; use the best name possible (solicit feedback if necessary).
  • Think of names as tiny comments
  • Use shorter names for shorter scope, longer names for larger scope
  • Only abbreviate well known (industry wide) abbreviations. If someone new would not know the abbreviation, do not use it. For example, Ssn (social security number), Url, Html. Not Gpijc (Giant Project I Just Created).
  • Use a name that describes the variable's value
  • If you're going to use a generic name like tmp, it, or retval, have a good reason for doing so
  • Taking time to come up with a good name will build your 'naming muscle'
  • If there is something important about a variable that the reader must know, it's worth attaching an extra word to the name
  • If you variable is a measurement it's helpful to encode the units into the variable's name
  • Prefix names with min/max for inclusive limits, or sometimes first/last if min/max doesn't sound correct. (firstPerson, lastPerson) When one end of the range is exclusive, add the inclusive/exclusive prefix: inclusiveMinAmount, exclusiveMaxAmount
  • Functions/methods should be named according to what they do (and they should do exactly that).
  • Acronyms should begin with a capital letter, but the rest of the letters should be lowercase 
  • Only use prefixes when it adds clarity in the current context; do not use gratuitously
  • Avoid negated terms in booleans
  • Perform a critiquing process for potential names
  • Avoid gratuitous prefixes, for example, personName in Person, or 'App*'. Only use prefixes when it gives a name meaning in the current context or in the scope of the project seems reasonable for our project  
  • The best names are resistant to misinterpretation
  • Use pronounceable names
  • Function/variables have same level of abstraction
  • Beware of users' expectations about certain words. For example, users man expect get() or size() to be lightweight methods
  • Be consistent with naming across your project



  • Capitalize only the first letter in acronyms (expect when the acronym is within a naming rule that forces all uppercase, such as constants), (e.g. 'KimConstants' instead of 'KIMConstants')


  • Capitalize the first letter of each word in the class or interface name  KULRICE-11059 - Data cannot be retrieved due to an unexpected error
  • Use nouns (person, place, or thing)
  • Pluralize names of classes that group related attributes, static services, or constants (ex. 'Utils', 'Constants')
  • Don't use Kuali in the name. Don't use module in the name unless necessary to differentiate (ex. 'KewConstants', 'KimConstants' is ok)
  • Use nouns to name interfaces that act as service declarations, use adjectives to name interfaces that act as descriptions or capabilities ('Activateable', 'Renderable')

  • Avoid interface-specific suffixes line 'I' or 'Interface' (e.g. AccountService instead of IAccountService); FooService for an interface and FooServiceImpl for the implementation class
  • Abstract classes should have the name suffix 'Base' (e.g. 'ControlBase', 'ComponentBase')
  • Names DTO Interfaces as '{dto}Contract' (e.g. Bar implements BarContract)

Rice Specific Type Naming

TypeNaming Convention
Presentation Controller{Qualifer}PresentationController


  • Use lowercase for the first word and capitalize only the first letter of each subsequent word that appears in a method name
  • Use active verbs when naming methods
  • Follow the JavaBeans conventions for naming property accessor methods ('get','set','is')


  • Use lowercase for the first word and capitalize only the first letter of each subsequent word that appears in a variable name
  • Use nouns to name variables
  • Pluralize the names of collection references, with the exception of maps end with 'Map', and in some cases end with 'List' (ex. ?)
  • Quality field variables with "this" to distinguish them from local variables

  • Iteration variables can be simple, like i, but if there are multiple indexes being used (for example, multi-dimensional arrays or loops within loops), use more descriptive names
  • Variables that flip rendering logic should be named render{Descriptor} (e.g. 'renderHeader')

Acceptable Short Variable Names

Variable NameUsage
eVariable for generic Exception
tVariable for generic Throwable
iop, npe, etc.Variable abbreviations for specific Exceptions
in, outInputStream and OutputStream
iIndex loop variable


  • Use nouns when naming enums
  • Use full description with uppercase words separated by underscores for enum constants


  • Use uppercase letters for each word and separate each word with an underscore when naming constants (e.g. 'GLOBAL_MESSAGE_KEY')

Method Arguments

  • When a constructor or "set" method assigns a parameter to a field, give that parameter the same name as the field 


  • Use single, lowercase word for root name of each package
  • All rice packages should have the form: org.kuali.rice.{module}

Also see Package Naming Standards

Published Service Names

When a service is published to the Service Registry in KSB, it's name becomes the identifier that other applications will use to look it up.

Service names are defined as a "Qualified Name" which means that they include both a "Namespace URI" as well as the "Local Part". See the javadocs for javax.xml.namespace.QName for more information:

The standard format for these services names is as follows:

Namespace URI:{module}/{major version}
Service Name:
A name starting with a lowercase letter that matches the name of the service interface (in the case that it's a singleton, if it's not a singleton service, a reasonably descriptive name should be chosen)

The "module" in this case is the top-level module abbreviation (like kew, kim, core, etc.). The major version in this case is the major version that the service was introduced in in the following fashion: "v2_0"

So, for example, the "NamespaceService" from the Rice core would be published under the following name:

  • Namespace URI:
  • Service Name: namespaceService

Note that you will often see the service name written as {}namespaceService

This is because this is what QName.toString returns.

See "Service Publishing Configuration" section of Maintaining Version Compatibility in Kuali Rice for more information.



  • By default, follow Java conventions where possible
  • Names should be formed from the 26 upper and lower case letters (A .. Z, a .. z), the 10 digits (0 .. 9), and _ (underbar), with the exception of $ for jQuery variables


  • Use underscore to prefix internal methods like jQuery does (e.g. '_fill()')
  • Constructor functions which must be used with the new prefix should start with a capital letter

Function Arguments

  • Optional parameters should be named 'opt_' in addition to be marked as optional on the \@ parm tag
  • Functions that take a variable number of arguments should have the last argument named 'var_args'. You may not refer to var_args in the code; use the arguments array.


  • Use '$' to prefix jQuery variables (e.g. '$div')
  • Global variables should be namespaced or put in an object


  • Global constants should be in uppercase

File Naming

  • All JS files should have the format {module}.{descriptor}.js, all lowercase. Use view id as descriptor for view specific js (e.g. 'kew.actionlist.js')



  • First character of each word in the Id should be uppercased
  • The first word of each Id should be the module id followed by a dash and one or more descriptors, {ModuleId}-{descriptor}-{descriptor} (e.g. 'Kew-ActionList')
  • All base UIF beans start with 'Uif-' (e.g. 'Uif-TextControl')

Id formats for specific beans

Bean TypeId
Maintenance Document{DataObjectName}MaintenanceDocument
Transactional Document{Descriptor}Document
Key Values Finder{Descriptor}KeyValuesFinder


  • Service bean ids should be same as the interface name (the bean implements), except first character should be lowercase (e.g. Interface is 'AccountService', bean id 'accountService')

XML files should be named as follows:

Data Object Entry{DataObjectName}.xml
Lookup and Inquiry Views{DataObjectName}Views.xml
Maintenance Document{DataObjectName}Document.xml
Transactional Document{Qualifier}Document.xml
Service beans (e.g. 'KradSpringBeans.xml'){Qualifier}SpringBeans.xml

The document entry should be part of {DataObjectName}Views.xml.

Document Type

  • The document type name, as specified in <documentType><name>, is composed of the data object name of the maintenance object or the qualifier for transactional documents suffixed with Document.
  • The file name of the document type definition matches the document type name and has the .xml file extension.
TypeDocument Type NameFile Name
Maintenance Document{DataObjectName}Document{DataObjectName}Document.xml
Transactional Document{Qualifier}Document{Qualifier}Document.xml



  • UIF base classes should have the format 'uif-{componentName}'  
  • All other CSS classes start with {module}-component (e.g. 'kew-actions')  
  • Name css files as {module}-{descriptor}.css.  Use view id as add. descriptor e.g. kew.actionList.css

File Naming:

  • All CSS files should have the format {module}-{descriptor}.css (e.g. 'krad-actions.css'), all lowercase. When the CSS is for a particular view, use the view id as the descriptor (e.g. 'kew-actionlist.css')


See Database Table and Column Name Standards

System Parameters

  • Look at other similar parameters and try to be consistent
  • Do not abbreviate
  • Names must be in all upper case
  • Use underscores to separate words
  • The list of valid values for component/detailed type is built from what's actually in KRNS_PARM_DTL_TYP_T, the simple name of all business object classes, the class names of all documents, and the names of batch steps in spring. Please make sure that you either consult these sources or use the component lookup when deciding what component should be used
  • Refer to entities by the same name under which they are listed in the component/detailed type lookup (substituting underscores for case changes)
  • Avoid the use of the words VALID, INVALID, ALLOW, DENY, and RESTRICTED, unless otherwise specified below. The constraint column should account for that information.
    • Caveat: If the code does not use the constraint parameter, then use of one of the above words may be applicable
  • Always provide a good description. Do not leave the description blank and do not copy from another, unrelated parameter. Do not duplicate information in the other fields that may change, e.g. do not describe as valid values when that could be changed by a user changing the constraint. If it makes sense, refer to the part of the application which uses the parameter so it's easier to find the usage of a parameter
  • Parameters that can have a value of Y or N should have a suffix of _IND.  (e.g. 'SHOW_ACCOUNT_WARNING_IND')
  • If a parameter can contain a list of items, it's name should be pluralized. (e.g., 'COST_SHARE_OBJECT_TYPES')

Standard Parameter Name Suffixes

Data Type


boolean (Y/N indicator)


business object key value

use the name of the business object as the suffix: e.g. _CHART, _ACCOUNT

email address




Misc Naming

Config Properties


  1. All config properties should be prefixed with rice.<rice module name>

Property Names

  1. Property names should use camel-case starting with a lowercase letter (i.e. noRefresh)

Using Configuration Properties from Code

  1. Config properties should be available from a constants class within the module constants (e.g. 'NO_REFRESH')