Gosu naming and declaration best practices

Observe general Gosu naming conventions

As a best practice, Guidewire recommends the following general naming conventions.

Language Element  

Naming Conventions

Examples

Variable names

Name variables in mixed case, with the first letter lowercase and the first letter of each internal word capitalized. Name variables mnemonically so that someone reading your code can understand and easily remember what your variables represent. Do not use single letters such as “x” for variable names, except for short-lived variables, such as loop counts.

nextPolicyNumber

firstName

recordFound

Function names

Compose function names in verb form. Name functions in mixed case, with the first letter lowercase and the first letter of each internal word capitalized. Add the suffix _Ext to the ends of function names to avoid future naming conflicts if Guidewire adds or changes base functions.

getClaim_Ext()

getWageLossExposure_Ext()

Class name

Compose class names in noun form. Name classes in mixed case, with the first letter uppercase and the first letter of each internal word capitalized. Add the suffix _Ext to the ends of class names to avoid future naming conflicts if Guidewire adds or changes base classes.

StringUtility_Ext

MathUtility_Ext

Omit type specifications with variable initialization

Type specifications in variable declarations are optional in Gosu if you initialize variables with value assignments. Whenever you initialize a variable, Gosu sets the type of the variable to the type of the value. As a best practice, Guidewire recommends that you always initialize variables and omit the type specification.

var amount = 125.00  // use an initialization value to set the type for a variable
var string = new java.lang.String("") // initialize to the empty string instead of null

Add a suffix to functions and classes to avoid name conflicts

In future releases, Guidewire may add or change base classes and functions. If you make changes to Guidewire packages, there is the possibility of a naming conflict with one of these future updates. For example, you may add enhancement methods or properties to existing Guidewire entities or classes. To avoid possible naming conflicts, Guidewire recommends that you append the suffix _Ext to your new functions and classes. For example, name a new function that calculates the days between two dates calculateDaysApart_Ext(...).

You generally will not modify Guidewire classes or packages directly. Instead, create new code within your own package space. Code in your own package does not require a suffix, as it will not conflict with base Guidewire changes. Add a suffix only if there is a possibility of a naming conflict with Guidewire base code.

Declare functions Private unless absolutely necessary

As a best practice, Guidewire recommends that you declare functions as public only with good reason. The default access in Gosu is public. So, declare functions as private if you intend them only for use internally within a class or class extension. Always prefix private and protected class variables with an underscore character (_).

Use public properties instead of public variables

As a best practice, Guidewire recommends that you convert public variables to properties. Properties separate the interface of an object from the implementation of its storage and retrieval. Although Gosu supports public variables for compatibility with other languages, Guidewire strongly recommends public properties backed by private variables instead of public variables.

The following sample Gosu code declares a private variable within a class and exposes it as a public property by using the as keyword. This syntax makes automatic getter and setter property methods that the class instance variable backs.

private var _firstName : String as FirstName  // Delcare a public property as a private variable. 

Avoid declaring public variables, as the following sample Gosu code does.

public var FirstName : String                 // Do not declare a public variable.

See also

Do not declare static scope for mutable variables

As a best practice, Guidewire recommends that you do not use static scope declaration for fields that an object modifies during its lifetime. Static fields have application scope, so all sessions in the Java Virtual Machine (JVM) share them. All user sessions see the modifications that made any user session makes to static properties.

For example, the following sample Gosu code is a bad example.

class VinIdentifier {
  static var myVector = new Vector()  // All sessions share this static variable.

   static function myFunction(){
    myVector.add("new data")     // Add data for the entire JVM, not just this session.
  }

 }

Use extensions to add functions to entities

As a best practice, Guidewire recommends that you add functions that operate on entities as extensions to the existing entity type instead of as static functions on separate utility classes.

Implement functions that operate on single entity instances as extensions

If you want a new function that operates on single instances of an entity type, declare the new function in a separate class extension to that entity type.

For example, you want a new function to suspend a policy. Name your new function suspend. Do not declare the function as static with a Policy instance as its parameter. Instead, declare the function as an extension of the Policy class, so callers can invoke the method directly on a Policy instance. For example:

if policy.suspend() {
  // Do something to suspend the policy.
}

Package entity extensions for an entity type in a single package

Package all of your extensions for an entity type together in a package with the same name as the entity they extend. Do not place all of your entity extensions in a single package. Place all of your extension packages in a package folder that identifies your organization.

For example, place all of your extensions to the Activity entity type in a package named com.CustomerName.activity.

Match capitalization of types, keywords, and symbols

Access existing types exactly as they are declared, including correct capitalization. Use the Gosu editor’s code completion feature to enter the names of types and properties correctly.

The following table lists conventions for capitalization of various Gosu language elements:

Language element

Standard capitalization

Example

Gosu keywords

Always specify Gosu keywords correctly, typically lowercase.

if

Type names, including class names

Uppercase first character

DateUtil

Claim

Local variable names

Lowercase first character

myClaim

Property names

Uppercase first character

CarColor

Method names

Lowercase first character

printReport

Package names

Lowercase all letters in packages and subpackages

com.mycompany.*

Some entity and typelist APIs are case insensitive if they take String values for the name of an entity, a property, or a typecode. However, it is best write your code as if they are case sensitive.

See also