Gosu naming and declaration best practices
Guidewire recommends a number of best practices for naming and declaring Gosu variables, functions, and classes.
- Observe general Gosu naming conventions
- Omit type specifications with variable initialization
- Add a suffix to functions and classes to avoid name conflicts
- Declare functions Private unless absolutely necessary
- Use public properties instead of public variables
- Do not declare static scope for mutable variables
- Use extensions to add functions to entities
- Match capitalization of types, keywords, and symbols
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. |
|
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
|
|
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
|
|
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 variablevar 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. |
|
|
Type names, including class names |
Uppercase first character |
|
|
Local variable names |
Lowercase first character |
|
|
Property names |
Uppercase first character |
|
|
Method names |
Lowercase first character |
|
|
Package names |
Lowercase all letters in packages and subpackages |
|
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
