Guidewire

PolicyCenter®

Best Practices Guide

R E L EA S E 9. 0 . 0
Copyright © 2001-2016 Guidewire Software, Inc.
Guidewire, Guidewire Software, Guidewire ClaimCenter, Guidewire PolicyCenter, Guidewire BillingCenter,
Guidewire Reinsurance Management, Guidewire ContactManager, Guidewire Vendor Data Management,
Guidewire Client Data Management, Guidewire Rating Management, Guidewire InsuranceSuite, Guidewire
ContactCenter, Guidewire Studio, Guidewire Product Designer, Guidewire Live, Guidewire DataHub, Guidewire
InfoCenter, Guidewire Standard Reporting, Guidewire ExampleCenter, Guidewire Account Manager Portal,

Guidewire Claim Portal, Guidewire Policyholder Portal, Guidewire Spotlight, Gosu, Adapt and succeed, and the
Guidewire logo are trademarks, service marks, or registered trademarks of Guidewire Software, Inc. in the
United States and/or other countries.
All other trademarks are the property of their respective owners.
This material is confidential and proprietary to Guidewire and subject to the confidentiality terms in the
applicable license agreement and/or separate nondisclosure agreement.
Guidewire products are protected by one or more United States patents.
Product Name: Guidewire PolicyCenter
Product Release: 9.0.0
Document Name: PolicyCenter Best Practices Guide
Document Revision: 24-June-2016
 PolicyCenter 9.0.0 Best Practices Guide

Contents
About PolicyCenter Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conventions in This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Data Model Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Entity Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Observe General Entity Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Add a Prefix or Suffix to Entity Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Use Singular for Field Names Except for Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Add ID as a Suffix to Column Names for Foreign Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Typelist Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Observe Typelist Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Add a Suffix to New Typelists and Typecode Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Data Model Best Practices Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 User Interface Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Page Configuration Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Modify Base PCF Files Whenever Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Add a Suffix to New PCF Files to Avoid Name Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Display Keys Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Use Display Keys to Display Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Use Existing Display Keys Whenever Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Observe Display Key Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Add a Suffix to New Display Keys to Avoid Name Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . 17
Organize Display Keys by Page Configuration Component. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
User Interface Performance Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Avoid Post on Change and Client Reflection for Page Refreshes . . . . . . . . . . . . . . . . . . . . . . 17
Avoid Repeated Calculations of Expensive Widget Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Avoid Expensive Calculations of Widget Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Use Application Permission Keys for Visibility and Editability . . . . . . . . . . . . . . . . . . . . . . . 19
User Interface Best Practices Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Rules Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Rules Naming Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Observe Rule Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Observe Operating System Length Restrictions on Rule Names . . . . . . . . . . . . . . . . . . . . . . . 23
Get and Display Rule Names in Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Assign a Dedicated Rules Librarian to Manage Rule Names . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Rules Performance Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Purge Unused and Obsolete Rules Before Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Rules Best Practices Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Contents 3
PolicyCenter 9.0.0 Best Practices Guide

4 Gosu Language Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Gosu Naming and Declaration Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Observe General Gosu Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Omit Type Specifications with Variable Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Add a Suffix to Functions and Classes to Avoid Name Conflicts . . . . . . . . . . . . . . . . . . . . . . 28
Declare Functions Private Unless Absolutely Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Use Public Properties Instead of Public Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Do Not Declare Static Scope for Mutable Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Use Extensions to Add Functions to Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Match Capitalization of Types, Keywords, and Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Gosu Commenting Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Comment Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Block Comments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Javadoc Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Single-line Comments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Trailing Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Using Comment Delimiters to Disable Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Gosu Coding Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Use Whitespace Effectively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Use Parentheses Effectively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Use Curly Braces Effectively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Program Defensively Against Conditions that Can Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Omit Semicolons as Statement Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Use != Instead of <> as the Inequality Operator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Observe Null Safety with Equality Operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Use typeis Expressions for Automatic Downcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Observe Loop Control Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Return from Functions as Early as Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Use Query Builder APIs instead of Find Expressions in New Code . . . . . . . . . . . . . . . . . . . . 38
Gosu Performance Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Use the Fastest Technique for String Concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Consider the Order of Terms in Compound Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Avoid Repeated Method Calls Within an Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Remove Constant Variables and Expressions from Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Avoid Doubly Nested Loop Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Pull Up Multiple Performance Intensive Method Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Be Wary of Dot Notation with Object Access Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Avoid Code that Incidentally Queries the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Use Comparison Methods to Filter Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Use Comparison Methods Instead of the Where Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Use Count Properties on Query Builder Results and Find Queries . . . . . . . . . . . . . . . . . . . . . 44
Use Activity Pattern Codes Instead of Public IDs in Comparisons . . . . . . . . . . . . . . . . . . . . . 45
Do Not Instantiate Plugins for Every Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Gosu Best Practices Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Upgrade Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Upgradability Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Add Minor Changes Directly to Base Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Copy Base Files to Add Major Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Copy Base Functions to Make Major Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Switching From Minor to Major Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Upgrade Best Practices Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Rating Management Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Rating Management Component Naming Conventions Best Practices . . . . . . . . . . . . . . . . . . . . . 51

4 Contents
 PolicyCenter 9.0.0 Best Practices Guide

Rate Book Edition Naming Conventions Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Rate Routine Step Naming Conventions Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Rating Management Best Practices Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Contents 5
PolicyCenter 9.0.0 Best Practices Guide

6 Contents
 PolicyCenter 9.0.0 Best Practices Guide

About PolicyCenter Documentation

The following table lists the documents in PolicyCenter documentation.

Document Purpose

InsuranceSuite Guide If you are new to Guidewire InsuranceSuite applications, read the InsuranceSuite Guide for
information on the architecture of Guidewire InsuranceSuite and application integrations.
The intended readers are everyone who works with Guidewire applications.
Application Guide If you are new to PolicyCenter or want to understand a feature, read the Application Guide.
This guide describes features from a business perspective and provides links to other books
as needed. The intended readers are everyone who works with PolicyCenter.
Upgrade Guide Describes the overall PolicyCenter upgrade process, and describes how to upgrade your
PolicyCenter database from a previous major version. The intended readers are system
administrators and implementation engineers who must merge base application changes
into existing PolicyCenter application extensions and integrations.
Configuration Upgrade Guide Describes how to upgrade your PolicyCenter configuration from a previous major version.
The intended readers are system administrators and implementation engineers who must
merge base application changes into existing PolicyCenter application extensions and inte-
grations. The Configuration Upgrade Guide is published with the Upgrade Tools, and is
available on the Guidewire Resource Portal.
New and Changed Guide Describes new features and changes from prior PolicyCenter versions. Intended readers
are business users and system administrators who want an overview of new features and
changes to features. Consult the “Release Notes Archive” part of this document for changes
in prior maintenance releases.
Installation Guide Describes how to install PolicyCenter. The intended readers are everyone who installs the
application for development or for production.
System Administration Guide Describes how to manage a PolicyCenter system. The intended readers are system admin-
istrators responsible for managing security, backups, logging, importing user data, or appli-
cation monitoring.
Configuration Guide The primary reference for configuring initial implementation, data model extensions, and
user interface (PCF) files. The intended readers are all IT staff and configuration engineers.
PCF Reference Guide Describes PolicyCenter PCF widgets and attributes. The intended readers are configuration
engineers.
Data Dictionary Describes the PolicyCenter data model, including configuration extensions. The dictionary
can be generated at any time to reflect the current PolicyCenter configuration. The intended
readers are configuration engineers.
Security Dictionary Describes all security permissions, roles, and the relationships among them. The dictionary
can be generated at any time to reflect the current PolicyCenter configuration. The intended
readers are configuration engineers.
Globalization Guide Describes how to configure PolicyCenter for a global environment. Covers globalization top-
ics such as global regions, languages, date and number formats, names, currencies,
addresses, and phone numbers. The intended readers are configuration engineers who
localize PolicyCenter.
Rules Guide Describes business rule methodology and the rule sets in PolicyCenter Studio. The
intended readers are business analysts who define business processes, as well as pro-
grammers who write business rules in Gosu.

About PolicyCenter Documentation 7

PolicyCenter 9.0.0 Best Practices Guide

Document Purpose

Contact Management Guide Describes how to configure Guidewire InsuranceSuite applications to integrate with
ContactManager and how to manage client and vendor contacts in a single system of
record. The intended readers are PolicyCenter implementation engineers and
ContactManager administrators.
Best Practices Guide A reference of recommended design patterns for data model extensions, user interface,
business rules, and Gosu programming. The intended readers are configuration engineers.
Integration Guide Describes the integration architecture, concepts, and procedures for integrating
PolicyCenter with external systems and extending application behavior with custom pro-
gramming code. The intended readers are system architects and the integration program-
mers who write web services code or plugin code in Gosu or Java.
Java API Reference Javadoc-style reference of PolicyCenter Java plugin interfaces, entity fields, and other utility
classes. The intended readers are system architects and integration programmers.
Gosu Reference Guide Describes the Gosu programming language. The intended readers are anyone who uses
the Gosu language, including for rules and PCF configuration.
Gosu API Reference Javadoc-style reference of PolicyCenter Gosu classes and properties. The reference can
be generated at any time to reflect the current PolicyCenter configuration. The intended
readers are configuration engineers, system architects, and integration programmers.
Glossary Defines industry terminology and technical terms in Guidewire documentation. The intended
readers are everyone who works with Guidewire applications.
Product Model Guide Describes the PolicyCenter product model. The intended readers are business analysts and
implementation engineers who use PolicyCenter or Product Designer. To customize the
product model, see the Product Designer Guide.
Product Designer Guide Describes how to use Product Designer to configure lines of business. The intended read-
ers are business analysts and implementation engineers who customize the product model
and design new lines of business.

Conventions in This Document

Text style Meaning Examples

italic Emphasis, special terminology, or a book title. A destination sends messages to an

external system.
bold Strong emphasis within standard text or table text. You must define this property.
narrow bold The name of a user interface element, such as a button Next, click Submit.
name, a menu item name, or a tab name.
monospaced Literal text that you can type into code, computer output, Get the field from the Address object.
class names, URLs, code examples, parameter names,
string literals, and other objects that might appear in pro-
gramming code. In code blocks, bold formatting highlights
relevant sections to notice or to configure.
monospaced italic Parameter names or other variable placeholder text within Use getName(first, last).
URLs or other code snippets.
http://SERVERNAME/a.html.

Support
For assistance with this software release, contact Guidewire Customer Support:
• At the Guidewire Resource Portal – http://guidewire.custhelp.com

8 About PolicyCenter Documentation

 PolicyCenter 9.0.0 Best Practices Guide

• By email – support@guidewire.com
• By phone – +1-650-356-4955

9
PolicyCenter 9.0.0 Best Practices Guide

10 Chapter :
chapter 1

Data Model Best Practices

The PolicyCenter data model comprises metadata definitions of data entities that persist in the PolicyCenter
application database. Metadata definition files let you define the tables, columns, and indexes in the relational
database that supports your application. Typelist definitions let you define sets of allowed codes for specific
typekey fields on entities.
This topic includes:
• “Entity Best Practices” on page 11
• “Typelist Best Practices” on page 13
• “Data Model Best Practices Checklist” on page 13

Entity Best Practices

You can change the base data model of PolicyCenter to accommodate your business needs with data model
extensions. Extensions let you add fields to existing data entities and add entirely new data entities to the data
model of your PolicyCenter application. PolicyCenter uses the data model and your extensions to create and
manage the tables, columns, and indexes in the relational database that supports your application.
As a best practice, Guidewire recommends that you edit the metadata definition files of the data model by using
the Data Model Extensions editor in Guidewire Studio.

See also
• “The PolicyCenter Data Model” on page 163 in the Configuration Guide

Observe General Entity Naming Conventions

Generally, entity and field names begin with a capital letter. Medial capitals separate words in compound entity
names. For example, ContactAddress.

Data Model Best Practices 11

PolicyCenter 9.0.0 Best Practices Guide

Add a Prefix or Suffix to Entity Extensions

To avoid future naming conflicts when Guidewire adds or changes base entities, Guidewire recommends that you
add Ext to your entity names and new field names on base entities.
• As a prefix – Add Ext_ to beginnings of entity names so Studio and the Data Dictionary list them together in
one group. For example, Ext_ServiceArea.
• As a suffix – Add _Ext to endings of entity names so Studio and the Data Dictionary list them next to any
entities that they extend. For example, CreditHistory_Ext.
If you add a new entity, its field names do not need Ext in their names, because you have Ext in the name of the
entity.
As an example of field extensions to a base entity, the following sample metadata file extends the base Policy
entity with an additional field (column) and an additional typekey.
<extension entityName="Policy">
...
<column desc="Description of the column"
name="MyCustomColumn_Ext"
nullok="true"
default="abc"
type="varchar"
<columnParam
name="size"
value="60" />
</column>

<typekey desc="Description of the typekey"

name="MyCustomTypekey_Ext"
typelist="myCustomTypeList_Ext)"
nullok="true" />
...
</extension>

Use Singular for Field Names Except for Arrays

Guidewire recommends that you name most fields with a singular word such as Phone or Age. However, because
array fields reference a list of objects, Guidewire recommends that you name them with a plural word.
For example, Policy.CurrentRoleAssignment and Policy.CorePolicyNumber are single fields on a Policy
entity, but Policy.RiskNotes is an array of multiple notes. Also, for arrays fields that are extensions, make the
primary name plural and not the Ext prefix or suffix. For example, use Ext_MedTreatments or
MedTreatments_Ext, and not MedTreatment_Exts.

Add ID as a Suffix to Column Names for Foreign Keys

Guidewire recommends that you add ID as a suffix to the column names of foreign keys. By default, the column
name of foreign keys have the same name as the foreign key names. Use the columnName attribute of foreignkey
elements to override their default column names. For example:
<foreignkey
columnName="PolicyID"
...
name="Policy"/>

Adding the suffix ID to the column names of foreign keys helps database administrators identify columns in the
database that Guidewire uses as foreign keys.
If you add a foreign key as an extension to a base entity, follow the best practice of adding a prefix or suffix to the
name. For example:
<foreignkey
columnName="Policy_ExtID"
...
name="Policy_Ext"/>

12 Chapter 1: Data Model Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Typelist Best Practices

A typelist represents a set of allowed values for specific fields on entities in the data model. A typecode repre-
sents an individual value within a typelist. A typecode comprises:
• A code that the database stores as a column value
• A name that the user interface displays
• A priority setting that drop-down lists use to order they typecode names that they display
As a best practice, Guidewire recommends that you edit typelist definitions by using the Typelist editor in
Guidewire Studio.

See also
• “Working with Typelists” on page 265 in the Configuration Guide

Observe Typelist Naming Conventions

The components of a typelist have these naming conventions:

Typelist Component Naming Conventions Example

Typelist Names begin with a capital letter. Medial capitals separate ActivityCategory
words.
Code Names contains only lower-case letters. Underscores (_) approval_pending
separate words.
Name Each word in a name begins with a capital letter. Spaces sep- Approval Pending
arate words.

Add a Suffix to New Typelists and Typecode Extensions

To avoid future naming conflicts when Guidewire adds or changes base typelists and typecodes, Guidewire
recommends that you append the suffix _Ext to your typelist names and typecode codes.
As an example of new typelists, name one that represents types of medical procedures
MedicalProcedureType_Ext. Name the typecodes in your new typelists without the suffix _Ext.
As an example of new typecodes in a base typelist, the following AddressType typelist has a new typecode for
service entrances.
Code Name Description Priority Retired
-------------------- ---------------- ----------- -------- -------
billing Billing Billing -1 false
business Business Business -1 false
home Home Home -1 false
other Other Other -1 false
service_entrance_Ext Service Entrance Service Entrance -1 false

Data Model Best Practices Checklist

Use the following checklist before you complete your data model configuration tasks to ensure that your data
model follows Guidewire best practices.

Best Practice to Follow Best Practice Was Followed

“Observe General Entity Naming Conventions” on page 11

“Add a Prefix or Suffix to Entity Extensions” on page 12
“Use Singular for Field Names Except for Arrays” on page 12

Typelist Best Practices 13

PolicyCenter 9.0.0 Best Practices Guide

Best Practice to Follow Best Practice Was Followed

“Add ID as a Suffix to Column Names for Foreign Keys” on page 12

“Observe Typelist Naming Conventions” on page 13
“Add a Suffix to New Typelists and Typecode Extensions” on page 13

14 Chapter 1: Data Model Best Practices

chapter 2

User Interface Best Practices

PolicyCenter uses page configuration format (PCF) files to render the PolicyCenter application. PCF files
contain metadata definitions of the navigation, visual components, and data sources of the user interface. Display
keys provide the static text that visual components of the user interface display.
This topic includes:
• “Page Configuration Best Practices” on page 15
• “Display Keys Best Practices” on page 16
• “User Interface Performance Best Practices” on page 17
• “User Interface Best Practices Checklist” on page 20

Page Configuration Best Practices

You can change the user interface of the PolicyCenter application by adding, changing, and removing PCF files
from the configuration of your PolicyCenter instance. As a best practice, Guidewire recommends that you edit
PCF files by using the Page Configuration (PCF) editor in Guidewire Studio.

See also
• “Using the PCF Editor” on page 311 in the Configuration Guide

Modify Base PCF Files Whenever Possible

Modify the base configuration files wherever they can be modified. Create new files only when absolutely neces-
sary.

User Interface Best Practices 15

PolicyCenter 9.0.0 Best Practices Guide

Add a Suffix to New PCF Files to Avoid Name Conflicts

Every page configuration file in your PolicyCenter instance must have a unique file name. The location of page
configuration files within the folder structure of page configuration resources does not ensure uniqueness. To
avoid future naming conflicts when Guidewire adds or changes base page configurations, Guidewire recom-
mends that you append the suffix _Ext to the names of your page configuration files.
For example, name a new list view for contacts on a policy PolicyContacts_ExtLV.

Display Keys Best Practices

A display key represents a single piece of user-viewable text. A display key comprises:
• A name to use in PCF files and Gosu code, where you want to display textual information
• A text value to display in place of the name, for each locale installed in your PolicyCenter instance
As a best practice, Guidewire recommends that you edit your display key definitions by using the Display Keys
editor in Guidewire Studio.

See also
• “Using the Display Keys Editor” on page 151 in the Configuration Guide
• “Localizing Display Keys” on page 44 in the Globalization Guide

Use Display Keys to Display Text

Guidewire strongly recommends that you define display keys for any text that you display to users through the
PolicyCenter user interface or in log messages. Do not use hard-coded String literals. Display keys help you
localize your configuration of PolicyCenter with translations for specific languages.

Use Existing Display Keys Whenever Possible

Before you create a new display key, search the existing display keys to find one with the text that you want. In
Guidewire Studio, open the display_localeCode.properties file for the language you are using. Then, type
the word or phrase you want. The Display Keys editor navigates to and highlights display keys that contain the
text or phrase in their names or values.

Observe Display Key Naming Conventions

Generally, display key names begin with a capital letter. Internal capitalization separates words in compound
display key names. For example:
ContactDetail

PolicyCenter represents display keys in a hierarchical name space. A period (.) separates display key names in
the paths of the display key hierarchy. For example:
Validation.Contact.ContactDetail

Generally, you specify text values for display key names that are leaves on the display keys resource tree. Gener-
ally, you do not specify text values for display key names that are parts of the path to a leaf display key. In the
preceding example, the display keys Validation and Validation.Contact have no text values, because they are
parts of a display key path. The display key ContactDetail has a text value, Contact Detail, because it is a leaf
display key with no child display keys beyond it.

16 Chapter 2: User Interface Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Add a Suffix to New Display Keys to Avoid Name Conflicts

To avoid future naming conflicts when Guidewire adds or changes base display keys, append the suffix _Ext to
your new display key names.
For example, your PolicyCenter instance has a branch of the display key hierarchy for text that relates to contact
validation.
Validation.Contact.ContactDetail
Validation.Contact.NewContact

You want to add a display key for the text Delete Contact. Add a new display key named DeleteContact_Ext.
Validation.Contact.ContactDetail
Validation.Contact.DeleteContact_Ext
Validation.Contact.NewContact

You can change the text for base display keys to change the text that the base configuration of the application
displays. Guidewire recommends that you use the base configuration display keys for this purpose so the base
configuration PCF files can just make use of the new values. If you add display keys with the suffix _Ext with
the intention of using them in the base configuration, the base configuration PCF files must be altered to use
them.

Organize Display Keys by Page Configuration Component

Guidewire recommends that you organize display keys under paths specific to the page configuration component
types and PCF file names where the text values of display keys appears. For example,
LV.Activity.Activities.DueDate

User Interface Performance Best Practices

The ways in which you configure the user interface of your PolicyCenter instance affects its performance. As
performance best practices for user interface configuration, Guidewire recommends that you always do the
following:
• “Avoid Post on Change and Client Reflection for Page Refreshes” on page 17
• “Avoid Repeated Calculations of Expensive Widget Values” on page 18
• “Avoid Expensive Calculations of Widget Properties” on page 19
• “Use Application Permission Keys for Visibility and Editability” on page 19

Avoid Post on Change and Client Reflection for Page Refreshes

As a performance best practice, Guidewire recommends that you not use postOnChange or client reflection
unless you absolutely must refresh your page for users in response to field changes.

Use Post On Change with Extreme Caution

As a performance best practice, Guidewire recommends that you use postOnChange fields with extreme caution
and only when client reflection cannot be used. Each edit that a user makes to a postOnChange field requires a
round trip to the server to refresh the page. So, an edit to a postOnChange field may create a latency in response
for the user. For pages with many queries, a single postOnChange can be slow and performance intensive as the
server executes each query again. Be sure to remove postOnChange whenever your need for immediate page
refresh goes away.

User Interface Performance Best Practices 17

PolicyCenter 9.0.0 Best Practices Guide

Use Client Reflection Instead of Post on Change If Possible

As a performance best practice, Guidewire recommends that you use client reflection instead of postOnChange if
client reflection satisfies you requirements for page refresh. For example, your page has two range widgets. The
choice a user makes in the first range widget determines the choices available in the second range widget. If you
make the first range widget a postOnChange field, the server incidentally executes every non-cached query on the
page again at least once. The user may have to wait a long time before the page lets the user choose from the
second range widget. If you use client reflection to update the second widget instead, you avoid a server round
trip and performance degradation to execute non-cached queries in the server.

Avoid Repeated Calculations of Expensive Widget Values

As a performance best practice, Guidewire recommends that you avoid repeated evaluation of performance
intensive expressions for widget values. Depending on the needs of your application, performance intensive
expressions may be unavoidable. However, you can improve overall performance of a page by choosing care-
fully where to specify the expression within the page configuration.
For example, the following value range expression has a performance problem. Evaluation of the expression
requires two foreign key traversals and one array lookup. If the PolicyPeriod instance is not cached,
PolicyCenter executes three relational database queries, which makes the evaluation even more expensive.
RangeInput
...
valueRange |policyPeriod.Policy.Product.AllowedPolicyTerms

If a page with this range input widget has any postOnChange fields, PolicyCenter potentially evaluates the
expression multiple times for each postOnChange edit that a user makes.

Use Page Variables Instead for Expensive Value Expressions

Instead of specifying an expensive expression as the value for a widget, create a page variable and specify the
expensive expression as the initial value. Then, specify the page variable as the value for the widget. Page vari-
ables are evaluated only during the construction of the page, not during the remaining lifetime of the page,
regardless of postOnChange edits.
The following example suffers a performance problem, because it assigns an expensive expression to the value
property of a widget.
Input: myInput
...
value |someExpensiveMethod()

The following modified sample code improves performance. It assigns a performance intensive expression to a
page variable and assigns the variable to the widget value.
Variables
...
initialValue |someExpensiveMethod()
name |expensiveResult

--------------------------------
Input: myInput
...
value |expensiveResult

Use Recalculate on Refresh with Expensive Page Variables Cautiously

PolicyCenter evaluates page variables only during the construction of the page, but sometimes you want
PolicyCenter to evaluate a page variable in response to postOnChange edits. If so, you set the
recalculateOnRefresh property of the page variable to true. If a page variable specifies an expensive expres-
sion for its initialValue, carefully consider whether your page really must recalculate the variable. If you set
the recalculateOnRefresh property to true, PolicyCenter evaluates the expression at least once for every
postOnChange edit to the page.

18 Chapter 2: User Interface Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Although PolicyCenter evaluates page variable with recalculateOnRefresh set to true for each postOnChange
edit, page variables can yield performance improvements compared to widget values. If several widgets use the
same expression for their values, using a page variable reduces the number of evaluations by a factor equal to the
number widgets that use it. For example, the valueRange of a range input used for drop-down lists in a list view
column are evaluated at least once for each row.

Do Not Use Post on Change with List Views

Do not use postOnChange with list views. Each row that a user inserts or removes causes a server round trip. To
update list totals, use client reflection instead.

Avoid Expensive Calculations of Widget Properties

Page configuration widget properties editable, visible, available, and required, may need to be evaluated
in multiple contexts. If you have a complex or expensive expression in one of these properties, move the expres-
sion to a page variable. Otherwise, the expression is evaluated several times before PolicyCenter displays the
page.
The following example suffers a performance problem. It assigns a performance intensive expression to the
visible property of a widget.
Input: myInput
...
id |myInput
...
visible |activity.someExpensiveMethod()

The following modified sample code improves performance. It assigns a performance intensive expression to a
page variable. PolicyCenter evaluates page variables only once before it displays a page, regardless how many
contexts under which it evaluates widget properties on the page.
Variables
...
initialValue |activity.someExpensiveMethod()
name |expensiveResult

--------------------------------
Input: myInput
...
id |myInput
...
visible |expensiveResult

Use Application Permission Keys for Visibility and Editability

The visible and editable properties are evaluated many times during the lifetimes of locations and widgets. As
a performance best practice, Guidewire recommends that you structure the page configuration of your user inter-
face so application permission keys determine visibility and editability. This is the most common pattern for user
access in business applications.
For example, use the following Gosu expression in the visible property of a Renew button on a panel that
displays information about a policy period.
perm.PolicyPeriod.renew(aPolicy)

Application permission keys evaluate the current user against general system permissions and the access control
lists of specific entity instances.

User Interface Performance Best Practices 19

PolicyCenter 9.0.0 Best Practices Guide

User Interface Best Practices Checklist

Use the following checklist before you complete your user interface configuration tasks to ensure that your user
interface configuration follows Guidewire best practices.

Best Practice to Follow Best Practice Was Followed

“Modify Base PCF Files Whenever Possible” on page 15

“Add a Suffix to New PCF Files to Avoid Name Conflicts” on page 16

“Use Display Keys to Display Text” on page 16

“Use Existing Display Keys Whenever Possible” on page 16

“Observe Display Key Naming Conventions” on page 16

“Add a Suffix to New Display Keys to Avoid Name Conflicts” on page 17

“Organize Display Keys by Page Configuration Component” on page 17

“Avoid Post on Change and Client Reflection for Page Refreshes” on page 17

“Use Post On Change with Extreme Caution” on page 17

“Use Client Reflection Instead of Post on Change If Possible” on page 18

“Avoid Repeated Calculations of Expensive Widget Values” on page 18

“Use Page Variables Instead for Expensive Value Expressions” on page 18

“Use Recalculate on Refresh with Expensive Page Variables Cautiously” on

page 18
“Use Application Permission Keys for Visibility and Editability” on page 19

20 Chapter 2: User Interface Best Practices

chapter 3

Rules Best Practices

PolicyCenter rules comprise hierarchies of conditions and actions that implement complex business logic. As a
best practice, Guidewire recommends that you edit rules by using the Rules editor in Guidewire Studio.
This topic includes:
• “Rules Naming Best Practices” on page 21
• “Rules Performance Best Practices” on page 24
• “Rules Best Practices Checklist” on page 25

See also
• “Rules: A Background” on page 11 in the Rules Guide

Rules Naming Best Practices

Guidewire recommends a number of rule naming best practices to help you identify and locate specific rules
during configuration, testing, and production.
• “Observe Rule Naming Conventions” on page 21
• “Observe Operating System Length Restrictions on Rule Names” on page 23
• “Get and Display Rule Names in Messages” on page 24
• “Assign a Dedicated Rules Librarian to Manage Rule Names” on page 24

Observe Rule Naming Conventions

Each rule name within a rule set must be unique. To help ensure uniqueness, Guidewire recommends that you
follow the best practices naming conventions for rules described in this topic. In addition, these naming conven-
tions help you quickly identify each rule within the complex hierarchy of rules in your Guidewire instance during
testing and in production.
The basic format for a rule name has two parts:
Identifier - Description

Rules Best Practices 21

PolicyCenter 9.0.0 Best Practices Guide

Follow these conventions for Identifier and Description:

• Separate Identifier from Description with a space, followed by hyphen, followed by a space.
• Limit Identifier to eight alphanumeric characters.

IMPORTANT Guidewire truncates Identifier values that exceed eight characters if you include the
actions.ShortRuleName property in rule actions to display rule names in messages that you log or
display. Guidewire also truncates Identifier values that exceed eight characters in automatic log
messages if you enable the RuleExecution logging category and set the server run mode to Debug.

• Begin Identifier with up to four capital letters to identify the rule set or parent rule of which the rule is a
member.
• End Identifier with at least four numerals to identify the ordinal position of the rule within the hierarchy of
rules in the set.
• For Description values, keep them simple, short, and consistent in their conventions.
• Limit the total length of rule names to 60 characters.
For example:
CV000100 - Future loss date

Rule Naming Summary Principles

Remember these principles for rule names:
• Rule names are unique within a rule set.
• Rules numbers are sequential to mimic the order of rules in the fully expanded set.
The following example demonstrates these principals.
Claim Validation Rules
CV001000 - Future loss date
CV002000 - Policy expiration date after effective date
CV002500 - Not Set: Coverage in question
CV003000 - Injury
CVI03100 - Workmen’s Compensation
CVIW3110 - Claimant exists
CVIW3120 - Not Set: Injury description
CV103900 - Default
CV004000 - Expected recovery exceeds 100

Root Rules Naming Conventions

Consider the following example rule set, Claim Validation Rules. The identifiers of rules in this set all begin
with CV, a code to identify “Claim Validation” rules.
Claim Validation Rules
CV001000 - Future loss date
CV002000 - Policy expiration date after effective date
CV003000 - Injury
CVI03100 - Workmen’s Compensation
CV103900 - Default
CV004000 - Expected recovery exceeds 100

The rule set contains four root rules, with identifiers CV001000, CV002000, CV003000, and CV004000. The
numbers at the end of the identifiers, 1000, 2000, 3000 and 4000, are units of one thousand. This spread of
numbers lets you add new root rules between existing ones without renumbering. You want identifier numbers
for rules in a set to remain in sequential order to mimic the order of rules within the fully expanded set.
For example, you want to add a rule between CV002000 and CV003000. Assign the new rule the identifier
CV002500.
Claim Validation Rules
CV001000 - Future loss date
CV002000 - Policy expiration date after effective date
CV002500 - Not Set: Coverage in question
CV003000 - Injury diagnosis validity dates

22 Chapter 3: Rules Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

CVI03100 - Workmen’s Compensation

CV103900 - Default
CV004000 - Expected recovery exceeds 100

Parent and Child Rules Naming Conventions

Many rule sets achieve their business function with simple rules in the root of the set. In preceding example,
rules CV001000, CV002000, CV002500, and CV004000 are simple root rules. Frequently however, rule sets achieve
their business function only with a hierarchy of parent and child rules. In the example, rule CV003000 is a parent
rule with two child rules.
When you add child rules to a parent, follow these conventions:
• Expand the beginning code for the child rules with an additional letter to identify their parent.
• Assign each child rule an ending number that falls between the number of the parent and the sibling rule that
follows the parent.
• Assign the children a spread of numbers so you can add more children later without renumbering.
In the preceding example, the identifiers for the child rules of CV003000 all begin with CVI, a code to identify
“Claim Validation Injury” rules.
Claim Validation Rules
...
CV003000 - Injury
CVI03100 - Workmen’s Compensation
CV103900 - Default
CV004000 - Expected recovery exceeds 100

The spread of numbers for child rules of a root parent rule generally are units of one hundred. This spread of
numbers lets you add new child rules between existing ones without renumbering. Most importantly, the
numbers of child rules must fall between the numbers of their parent rule and the sibling rule that follows their
parent. In this example, the numbers for child rules satisfy both conventions.
The parent and child naming convention applies to another, third level of children. For example, you want to add
two new child rules to the rule CVI03100 - Workmens’s Compensation. Begin the child identifiers with CVIW, a
code to identify “Claim Validation Injury Workmen’s Compensation” rules. At the third level of a rule set hier-
archy, the spread of numbers for the child rules generally are units of ten.
Claim Validation Rules
...
CV003000 - Injury
CVI03100 - Workmen’s Compensation
CVIW3110 - Claimant exists
CVIW3120 - Not Set: Injury description
CV103900 - Default
CV004000 - Expected recovery exceeds 100

Observe Operating System Length Restrictions on Rule Names

Guidewire stores rules in files within a directory structure that mimics the rule set category structure in Studio.
The fully qualified path for a rule file can be quite long, depending on:
• The length of the path to your Guidewire installation directory
• The length of the path from your installation directory to the root of the rules directory, which is 34 charac-
ters:
modules/configuration/config/rules
• The depth of the hierarchy of rule categories, rule sets, rules, and parent/child rules
• The length of individual rule names
In addition, you must add four characters to the path for the name of each rule category, rule set, and parent rule.
You must understand the file system implications of rule names. Windows file systems have a file path limit of
255 characters. To avoid exceeding the limit, Guidewire recommends that you:
• Avoid a long path to your Guidewire installation directory.

Rules Naming Best Practices 23

PolicyCenter 9.0.0 Best Practices Guide

• Avoid deep hierarchies of rule set categories.

• Avoid hierarchies of parent and child rules within a rule set deeper than three levels.
• Avoid long names for rule set categories, rule sets, and rules.

Get and Display Rule Names in Messages

As a best practice, Guidewire recommends that you get and display rule names in messages. So, following the
Guidewire best practices for rule names helps you identify specific rules in messages to users, in print statements
for testing, and in log messages. The alphabetic beginning of a rule identifier helps you find the rule set or parent
rule that contains the rule. The numeric ending helps you determine the order of a rule in a rule set or parent rule.
For example, you want to test a producer code validation rule, PCV01000 - No producer code roles. The iden-
tifier portion of the rule name begins with PCV. That identifies the rule as a member of the
ProduceCodeValidationRules rule set. The identifier ends with 01000. That indicates that rule is near the begin-
ning of the rule set. The rule has the following definition.
PCV01000 - No producer code roles
Rule Conditions:
producerCode.ProducerCodeRoles.Count == 0

Rule Actions:
producerCode.rejectField("ProducerCodeRoles", null, null, "loadsave",
"A role is required for producer code" + producerCode.Code + "."
)

As written, the rejection message that the rule action displays makes it difficult to determine exactly which rule
caused an update to fail. To help identify the specific rule in the rejection message, use the
actions.getRule().DisplayName property to include the identifier portion of the rule name in the message.
Rule Actions:
producerCode.rejectField("ProducerCodeRoles", null, null, "loadsave",
"A role is required for producer code " + producerCode.Code +
". Rule: " + actions.getRule().DisplayName.substring(8)
)

By including the rule display name in the rule action, users see the following statement in the Validation window
when the rule action executes.
A role is required for producer code ACME235. Rule: PCV01000

Note: In actual practice, Guidewire recommends that you make all String values into display keys.

Assign a Dedicated Rules Librarian to Manage Rule Names

As a best practice, Guidewire recommends that you appoint someone in your organization to develop and
enforce simple and consistent naming conventions for rule categories, rule sets, and rule names. This helps
ensure that naming standards are followed to make sure that rule identifiers readily identify specific rules within
the total catalog of rules in your Guidewire instance.

Rules Performance Best Practices

Guidewire recommends performance best practices for rules to help you avoid known performance issues.

Purge Unused and Obsolete Rules Before Upgrading

As a best practice, Guidewire recommends that you purge unused and obsolete rules from your PolicyCenter
configuration. This improves the upgrade process because PolicyCenter does not spend time to evaluate inactive
rules that are unused or obsolete.

24 Chapter 3: Rules Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Rules Best Practices Checklist

Use the following checklist before you complete your rule configuration tasks to ensure that your rules follow
Guidewire best practices.

Best Practice to Follow Best Practice Was Followed

“Observe Rule Naming Conventions” on page 21

“Rule Naming Summary Principles” on page 22

“Root Rules Naming Conventions” on page 22

“Parent and Child Rules Naming Conventions” on page 23

“Observe Operating System Length Restrictions on Rule Names” on page 23

“Get and Display Rule Names in Messages” on page 24

“Assign a Dedicated Rules Librarian to Manage Rule Names” on page 24

“Purge Unused and Obsolete Rules Before Upgrading” on page 24

Rules Best Practices Checklist 25

PolicyCenter 9.0.0 Best Practices Guide

26 Chapter 3: Rules Best Practices

chapter 4

Gosu Language Best Practices

Gosu is a general-purpose programming language built on top of the Java Virtual Machine. PolicyCenter uses
Gosu as its common programming language.
This topic includes:
• “Gosu Naming and Declaration Best Practices” on page 27
• “Gosu Commenting Best Practices” on page 30
• “Gosu Coding Best Practices” on page 32
• “Gosu Performance Best Practices” on page 38
• “Use Comparison Methods Instead of the Where Method” on page 43
• “Gosu Best Practices Checklist” on page 45

See also
• “Gosu Introduction” on page 15 in the Gosu Reference Guide

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” on page 28
• “Omit Type Specifications with Variable Initialization” on page 28
• “Add a Suffix to Functions and Classes to Avoid Name Conflicts” on page 28
• “Declare Functions Private Unless Absolutely Necessary” on page 28
• “Use Public Properties Instead of Public Variables” on page 28
• “Do Not Declare Static Scope for Mutable Variables” on page 29
• “Use Extensions to Add Functions to Entities” on page 29
• “Match Capitalization of Types, Keywords, and Symbols” on page 29

Gosu Language Best Practices 27

PolicyCenter 9.0.0 Best Practices Guide

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 an initial lower case letter nextPolicyNumber
and a medial capital for each internal word. Name variables firstName
mnemonically so that someone reading your code can under- recordFound
stand 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 getClaim_Ext()
mixed case, with an initial lower case letter and medial capi- getWageLossExposure_Ext()
tals for each internal word. Add the suffix _Ext to the ends of
function names to avoid future naming conflicts if Guidewire
adds or changes base functions.
Class name Compose class names in noun form. Name classes in mixed StringUtility_Ext
case, with an initial upper case and medial capitals for each MathUtility_Ext
internal word. Add the suffix _Ext to the ends of class names
to avoid future naming conflicts if Guidewire adds or changes
base classes.

Omit Type Specifications with Variable Initialization

Type specifications in variable declarations are optional in Gosu if you initialize variables with value assign-
ments. 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 intialization 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

To avoid future naming conflicts if Guidewire adds or changes base functions and classes, Guidewire recom-
mends 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(...).

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 vari-
ables 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.

28 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

For general information, see “Properties” on page 187 in the Gosu Reference Guide.

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 sepa-
rate 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.

Gosu Naming and Declaration Best Practices 29

PolicyCenter 9.0.0 Best Practices Guide

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

Language element Standard capitalization Example

Gosu keywords Always specify Gosu keywords correctly as they are declared, typically if
lowercase.
type names, including uppercase first character DateUtil
class names Claim
local variable names lowercase first character myClaim

property names uppercase first character CarColor

method names lowercase first character printReport

property names uppercase first character Name

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
• “Case Sensitivity” on page 25 in the Gosu Reference Guide

Gosu Commenting Best Practices

As a best practice, Guidewire recommends a variety of comment usages and styles.
• “Comment Placement” on page 30
• “Block Comments” on page 30
• “Javadoc Comments” on page 31
• “Single-line Comments” on page 31
• “Trailing Comments” on page 31
• “Using Comment Delimiters to Disable Code” on page 31

Comment Placement
As a commenting best practice, always place block comments before every class and method that you write.
Briefly describe the class or method in the block comment. For comments that you place within methods, use any
of the commenting styles to help clarify the logic of your code.

Block Comments
Block comments provide descriptions of libraries and functions. A block comment begins with a slash followed
by an asterisk (/*). A block comment ends with an asterisk followed by a slash (*/). To improve readability,
place an asterisk (*) at the beginnings of new lines within a block comment.
/*
* This is a block comment.
* Use block comments at the beginnings of files and before
* classes and functions.
*/

Place block comments at the beginnings of files, classes, and functions. Optionally, place block comments within
methods. Indent block comments within functions to the same level as the code that they describe.

30 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Javadoc Comments
Javadoc comments provide descriptions of classes and methods. A Javadoc comment begins with a slash
followed by two asterisks (/**). A Javadoc comment ends with a single asterisk followed by a slash (*/).
/**
* Describe method here--what it does and who calls it.
* How to Call: provide an example of how to call this method
* @param parameter description (for methods only)
* @return return description (for methods only)
* @see reference to any other methods,
* the convention is
* <class-name>#<method-name>
*/

Block comments that you format using Javadoc conventions allow automated Javadoc generation.

Single-line Comments
Single-line comments provide descriptions of one or more statements within a function or method. A single-line
comment begins with double slashes (//) as the first two characters two non-whitepsace characters on a line.
// Handle the condition
if (condition) {
...
}

If you cannot fit your comment on a single line, use a block comment, instead.

Trailing Comments
Trailing comments provide very brief descriptions about specific lines of code. A trailing comment begins with
double slashes (//) following the code that the comment describes. Separate the double slashes from the code
with at least two spaces.
if (a == 2) {
return true // Desired value of ’a’
}
else {
return false // Unwanted value of ’a’
}

If you place two or more trailing comments on lines in a block of code, indent them all to a common alignment.

Using Comment Delimiters to Disable Code

Use a single-line comment delimiter (//) to comment out a complete or partial line of code. Use a pair of block
comment delimiters (/*, */) to comment out a block of code, even if the block you want to comment out contains
block comments.
Note: Do not use single-line comment delimiters (//) on consecutive lines to comment out multiple lines of
code. Use block comment delimiters (/*, */), instead.
Use caution if you include slashes and asterisks within block comments to set off or divide parts of the comment.
For example, do not use a slash followed by a line of asterisks as a dividing line within a block comment. In the
following example, the compiler interprets the dividing line as the beginning of a nested comment (/*) but finds
no corresponding closing block comment delimiter (*/).
/*
The dividing line starts a nested block comment and causes an unclosed comment compiler error.
//********************************************************************************************
*/

In the preceding example, compilation fails due to an unclosed comment. The following example avoids compi-
lation errors by inserting a space between the slash and the first asterisk.
/*
The dividing line does not start a nested block comment and causes no compiler error.

Gosu Commenting Best Practices 31

PolicyCenter 9.0.0 Best Practices Guide

// **********************************************************************************
*/

Single-line comment delimiters (//) are ignored in block comments.

Gosu Coding Best Practices

Guidewire recommends a number of best practices for Gosu code.
• “Use Whitespace Effectively” on page 32
• “Use Parentheses Effectively” on page 32
• “Use Curly Braces Effectively” on page 32
• “Program Defensively Against Conditions that Can Fail” on page 33
• “Omit Semicolons as Statement Delimiters” on page 34
• “Use != Instead of <> as the Inequality Operator” on page 35
• “Observe Null Safety with Equality Operators” on page 35
• “Use typeis Expressions for Automatic Downcasting” on page 35
• “Observe Loop Control Best Practices” on page 36
• “Return from Functions as Early as Possible” on page 37
• “Use Query Builder APIs instead of Find Expressions in New Code” on page 38

Use Whitespace Effectively

Guidewire recommends the following best practices for effective use of whitespace:
• Add spaces around operators.
premium = Rate + (minLimit - reductionFactor) // proper form
premium=Rate+(minLimit-reductionFactor) // improper form
• Add no spaces between parentheses and operands.
((a + b) / (c - d)) // proper form
( ( a + b ) / ( c - d ) ) // improper form
• Indent logical blocks of code by two spaces only.
• Add a blank line after code blocks.
• Add two blank lines after methods, even the last method in a class.

Use Parentheses Effectively

As a best practice, Guidewire recommends that you always use parentheses to make explicit the operator order of
precedence in computational expressions. Otherwise, your computations can easily produce inappropriate
results. In the following sample Gosu code, the computation expression without parenthesis produces incorrect
results.
premium = (rate + limit) * (10.5 + deductible) / (autoGrade - 15) // proper form
premium = rate + limit * 10.5 + deductible / autoGrade - 15 // improper form, bad results

Math operators have a natural order of precedence, which controls the order of incremental computations in
compound computations if parentheses are absent. The following sample Gosu code makes explicit the operator
order of precedence in the computation without parentheses in the preceding example.
premium = rate + (limit * 10.5) + (deductible / autoGrade) - 15 // natural order of precedence

Use Curly Braces Effectively

Guidewire recommends the following best practices for effective use of curly braces:

32 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

• Surround every logical block, even single-statement blocks, with curly braces ({}).
• Put the opening curly braces ({) on the same line that starts the block.
• Put the closing curly brace (}) on the line after the last statement in the block, aligned with the starting
column of the block.
if(premium <= 1000) { // Put opening curly brace on line that starts the block.
print("The premium is " + premium) // Surround even single-line blocks with curly braces.
} // Put closing curly brace on line after last statement.

Program Defensively Against Conditions that Can Fail

As a best practice, Guidewire recommends that you program defensively. Always assume that conditions might
fail. Follow these recommendations to avoid common but easily missed programming flaws, such as potential
null pointer exceptions and out-of-bounds exceptions.

Use case-insensitive comparisons

Use the equalIgnoreCase method on the string literal to compare it with the value of a variable. Case mismatch
can cause comparisons to fail unintentionally.
if("Excluded".equalsIgnorecase(str)) { // proper comparison method
print("They match.")
}

if(string.equals("Excluded")) { // improper comparison method

print("They do NOT match.")
}

Check for null values

If your code cannot handle a variable that contains non-null values, check the variable for null before you access
properties on the variable.
function formatName (aUser : User) {
if (aUser != null) { // Check for null to avoid a null pointer exception later in the code.
print(aUser.DisplayName)
}
else {
print("No user")
}
}

Also, check variables for null before you call methods on variables:
function addGroup (aUser : User, : aGroupUser : GroupUser) {
if (aUser != null) { // Check for null to avoid a null pointer if you call methods on the variable.
aUser.addToGroup(aGroupUser)
}
}

Consider the following issues If you do not check variables for null:
• Accessing a property on a variable may use null-safe property access, which can cause null pointer exceptions
in later code that handles only non-null values.
• Calling a method on a variable risks a null pointer exception.

Allow default null-safe property access

If your code can handle a variable that contains null values, you can rely on null-safe access of simple properties
in most cases. With null-safe property access, the entire expression evaluates to null if the left-side of a period
operator is null.
For example, the following sample Gosu code returns null if the user object passed in by the caller is null.
Default null-safe property access prevents a null pointer exception in the return statement.
function formatName (aUser : User) : String {
return aUser.DisplayName // Default null-safe access returns null if the passed-in user is null.
}

Gosu Coding Best Practices 33

PolicyCenter 9.0.0 Best Practices Guide

Use explicit null-safe operators

If your code can handle an object path expression that evaluates to null, use the explicit Gosu null safe opera-
tors:
• ?. – Null-safe access to properties and methods
• ?[] – Null-safe access to arrays
The following sample Gosu code uses the explicit null-safe operator ?. to check for null to avoid a null pointer
exception while accessing a property. If aUser is null, the entire object path expression aUser?.DisplayName
evaluates to null.
function formatName (aUser : User) : String {
return aUser?.DisplayName // An explicit null-safe operator returns null if aUser is null.
}

The following sample Gosu code uses the explicit null safe operator ?. to check for null to avoid a null pointer
exception while calling a method. If aUser is null, Gosu does not call the method addToGroup, and the entire
expression aUser?.addToGroup(aGroupUser) evaluates to null.
function addGroup (aUser : User, aGroupUser: GroupUser) {
aUser?.addToGroup(aGroupUser) // An explicit null-safe operator returns null if aUser is null.
}

The following sample Gosu code uses the explicit null-safe operator ?[] to check for null to avoid a null pointer
exception while accessing an array. If strings[] is null, the entire expression strings?[index] evaluates to
null. However, the null-safe operator does not avoid out-of-bounds exceptions if strings[] is non-null and the
value of index exceeds the array length.
function getOneString (strings : String[], index : int) : String {
return = strings?[index] // An explicit null-safe operator evaluates to null if an array is null.
}

See also
• For more information about null-safe operators, see “Handling Null Values In Expressions” on page 84 in the
Gosu Reference Guide.

Check boundary conditions

In for loops, check for boundary conditions ahead of the loop. Entering a loop if the boundary condition is satis-
fied already can cause null pointer exceptions and out-of-bounds exceptions.

Use structured exception handling

Use try/catch blocks wherever required and possible. If you want to catch multiple exceptions, handle them in a
hierarchy from low-level, specific exceptions to high-level, generic exceptions.

Omit Semicolons as Statement Delimiters

Semicolons as statement delimiters are optional in Gosu. As a best practice, Guidewire recommends that you
omit semicolons. They are unnecessary in almost all cases, and your Gosu code looks cleaner and easier to read
without them.
// Omit semicolons with statements on separate lines.
print(x)
print(y)

Gosu requires semicolons only if you place multiple statements on a single line. As a best practice, Guidewire
generally recommends against placing multiple statements on a single line. Exceptions include simple statement
lists declared in-line within Gosu blocks.
// Include semicolons with multiple statements on a single line.
var adder = \ x : Number, y : Number -> { print("I added!"); return x + y; }

34 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Use != Instead of <> as the Inequality Operator

Use the != form instead of the <> form of the inequality operator. The <> form in earlier versions of Gosu is
deprecated. Studio provides a code inspection to flag this issue.
if (activitySubject != row.Name.text) { // The <> form of inequality operator is deprecated.
...
}

Observe Null Safety with Equality Operators

The equality and inequality comparison operators == and != are null safe if one side or the other evaluates to
null. Operators that are null safe do not throw null pointer exceptions. As a best practice, Guidewire recom-
mends that you use these comparison operators instead of the equals method on objects.
if (variable1 == variable2) { // Comparison operators are null safe.
print("The variables are equal.")
} else {
print("The variables are NOT equal.")
}

Rewrite Comparison Operators to Avoid the Equals Method

Do not write Gosu code that uses the equals method, because it is not type safe.
if (activitySubject.equals(row.Name.text) { // This expression is not null safe.
...
}

As a best practice, Guidewire recommends that you rewrite your Gosu code with comparison operators instead of
equals methods to make your code type safe and easier to read.
if (activitySubject == row.Name.text) { // This is expression is null safe and easier to read.
...
}

Avoid Implicit Type Coercion with Comparison Operators

Be aware of type coercion that occurs if you use the comparison operators == and != with operands of different
types. For example, the following expression evaluates to true.
1 == "1"

Gosu implicitly coerces "1" to an integer value of 1, without explicit casting. Implicit coercion is convenient and
powerful, but it can cause unexpected results if used without caution.
Gosu produces compiler warnings for implicit coercions. As a best practice, Guidewire recommends that you
take these warnings seriously. If you want the coercion, explicitly cast the operand on the right by using an
as Type expression. If you do not want the coercion, rewrite your code to avoid the implicit coercion.

For example, the following expression compares a date value to a string representation of a date value.
(dateValue == "2011-11-15")

Because Gosu coerces of the string "2011-11-15" to a date, rewrite the code with an explicit type cast.
(dateValue == "2011-11-15" as DateTime)

Use typeis Expressions for Automatic Downcasting

As a best practice, Guidewire recommends that you use typeis expressions to compare the type of an object with
a given subtype. After a typeis expression, Gosu automatically downcasts subsequent references to the object if
the object is of the type or a subtype of the original typeis expression. Use typeis expressions for automatic
downcasting to improve the readability of your code by avoiding redundant and unnecessary casts.

Gosu Coding Best Practices 35

PolicyCenter 9.0.0 Best Practices Guide

The automatic downcasting of typeis expressions is particularly valuable for if statements and similar Gosu
flow of control structures. Within the code block of an if statement, you can omit explicitly casting the object as
its subtype. Gosu confirms that the object is the more specific subtype and considers it be the subtype within the
if code block.

The following sample Gosu code shows a pattern for how to use a typeis expression with an if statement.
var variableName : TypeName // Declare a variable as a high-level type.

if (variableName typeis SubtypeName) { // Downcast the variable to one of its subtypes.

... // Use the variable as its subtype without explicit casting.
}

The following sample Gosu code follows the pattern and declares a variable as an Object. The if condition
downcasts the variable to its more specific subtype, String.
var x : Object = "nice" // Declare a String variable as type Object.
var strlen = 0

if (x typeis String) { // Downcast the Object variable to its subtype String.

strlen = x.length // Use the variable as a String without explicit casting.
}

Because Gosu propagates the downcasting from the if condition into the if code block, the expression x.length
is valid. The length property is on String, not Object.
The following sample Gosu code is equivalent to the preceding example, but it redundantly casts the variable as
a String within the if code block.
var x : Object = "nice" // Declare a String variable as type Object.
var strlen = 0

if (x typeis String) { // Downcast the Object variable to its subtype String.

strlen = (x as String).length // Explicit casting as String is redundant and unnecessary.
}

For general information, see “Basic Type Checking” on page 360 in the Gosu Reference Guide.

Observe Loop Control Best Practices

Gosu provides for(), while(), and do…while() statements for loop control. Guidewire recommends a few best
practices for your loop control logic.

Implement Conditional Operators in Loop Conditions Correctly

As a best practice, Guidewire recommends that you verify the conditional operators in your conditional expres-
sions to be certain that you fully satisfy the requirements for your loop control logic. For example, <, >, or =
might need to be <=, >=, or !=.

Interrupt Loop Execution as Early as Possible

As a best practice, Guidewire recommends that you interrupt loop execution as early as possible with continue
or break commands.

Use ‘break’ to Break Out of Loop Iteration Altogether

The break command stops execution of the loop altogether, and program execution proceeds immediately to the
code that follows the loop.
The following sample Gosu code breaks out of the loop altogether on the fourth iteration, when i equals 4.
for (i in 1..10) {
if (i == 4) {
break // Break out of the loop on the fourth iteration.
}

print("The number is " + i)

}

36 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

print("Stopped printing numbers")

The preceding sample Gosu code produces the following output.

The number is 1
The number is 2
The number is 3
Stopped printing numbers

Notice that the loop stops executing on the fourth iteration, when i equals 4.

Use ‘continue’ to Continue Immediately with the Next Loop Iteration

The continue command stops execution of the current iteration, and the loop continues with its next iteration.
The following sample Gosu code interrupts the fourth iteration, when i equals 4, but the loop continues
executing through all remaining iterations.
for (i in 1..10) {
if (i == 4) {
continue // End the fourth iteration here.
}

print("The number is " + i)

}

The preceding sample code produces the following output.

The number is 1
The number is 2
The number is 3
The number is 5
The number is 6
The number is 7
The number is 8
The number is 9
The number is 10

Notice that the loop continues through all nine iterations, but it interrupts the fourth iteration, when i equals 4.

Return from Functions as Early as Possible

As a best practice, Guidewire recommends that functions return as early as possible to avoid unnecessary
processing.
The following sample Gosu code is inefficient. The function uses a variable unnecessarily, and it does not return
a result as soon as it detects the affirmative condition.
public function foundThree() : boolean {
var threeFound = 0 // A numeric variable is unnecessary to return a boolean result.

for (x in 5) {
if (x == 3) {
threeFound = threeFound + 1 // The loop keeps iterating after third one is found.
}

return threeFound >= 1 // The function returns long after third one is found.
}

The following modified sample code is more efficient. The function returns a result as soon as it detects the affir-
mative condition.
public function foundThree() : boolean {
for (x in 5) {
if (x == 3) {
return true // The function returns as soon as the third one is found.
}

return false
}

Gosu Coding Best Practices 37

PolicyCenter 9.0.0 Best Practices Guide

Use Query Builder APIs instead of Find Expressions in New Code

As a best practice, Guidewire recommends that you query the database by using the query builder APIs instead
of find expressions in all new code. Guidewire developed the query builder APIs as an alternative way to query
the application database more fully than is possible with find expressions. For example, many requires joining
tables to produce useful results. The query builder APIs provide a fuller set of features for joining tables than find
expressions can specify. Furthermore, Gosu provides these enhanced capabilities using the structure of tradi-
tional API libraries rather than through a special language keyword.

See also
• “Query Builder APIs” on page 127 in the Gosu Reference Guide

Gosu Performance Best Practices

The ways in which you write your Gosu code affects compile-time and run-time performance. As best practices
for improving the performance of your code, Guidewire recommends that you always do the following:
• “Use the Fastest Technique for String Concatenation” on page 38
• “Consider the Order of Terms in Compound Expressions” on page 39
• “Avoid Repeated Method Calls Within an Algorithm” on page 39
• “Remove Constant Variables and Expressions from Loops” on page 40
• “Avoid Doubly Nested Loop Constructs” on page 40
• “Pull Up Multiple Performance Intensive Method Calls” on page 41
• “Be Wary of Dot Notation with Object Access Paths” on page 42
• “Avoid Code that Incidentally Queries the Database” on page 42
• “Use Comparison Methods to Filter Queries” on page 42
• “Use Comparison Methods Instead of the Where Method” on page 43
• “Use Count Properties on Query Builder Results and Find Queries” on page 44
• “Use Activity Pattern Codes Instead of Public IDs in Comparisons” on page 45
• “Do Not Instantiate Plugins for Every Execution” on page 45

Use the Fastest Technique for String Concatenation

As a performance best practice, Guidewire recommends that your code perform string concatenation using the
fastest technique for a given situation. If in doubt, concatenate strings by using a Java string builder.

Concatenation technique Performance Sample Gosu code

Concatenation (+) on literals Fastest var aString = "Test" + " Test"

Gosu string template Faster var aString : String

var anotherString : String = "Test"
aString = "Test ${anotherString}"
Java string builder Intermediate var aString = new java.lang.StringBuilder()
aString.append("Test")
aString.append(" Test")
Java string buffer Moderate var aString = new java.lang.StringBuffer()
aString.append("Test")
aString.append(" Test")

38 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Concatenation technique Performance Sample Gosu code

Concatenation (+) on a variable with a literal Slower var aString : String = "Test"
aString = aString + " Test"
Concatenation (+) on a variable with a variable Slowest var aString : String = "Test"
var anotherString : String = " Test"
aString = aString + anotherString

Consider the Order of Terms in Compound Expressions

As a performance best practice, Guidewire recommends that you carefully consider the order of comparisons in
compound expressions that use the and and or operators. Runtime evaluation of compound expressions that use
and proceed from left to right until a condition fails. Runtime evaluation of compound expressions that use or
proceed from left to right until a condition succeeds. The order in which you place individual conditions can
improve or degrade evaluation performance of compound expressions.

With and Expressions, Place Terms Likely to Fail Earlier

Whenever you use the and operator, place the condition that is most likely to fail or the least performance inten-
sive earliest in the compound expression. Use the following formula to help you determine which condition to
place first, based on the condition with the lowest value.
(100 - failurePercentage) * (performanceCost)

For example, you have a condition that you expect to fail 99% of the time, with an estimated performance cost of
10,000 per evaluation. You have another condition that you expect to fail only 1% of the time, with an estimated
performance cost of 100 per evaluation. According to the formula, place the second condition earliest because it
has the lowest score.
(100 - 99) * 10,000 = 10,000
(100 - 1) * 100 = 9,999

You rarely have accurate figures for the failure percentages or performance costs of specific condition. Use the
formula to develop an educated guess about which condition to place earliest. In general, give preference to less
performance intensive condition. If the performance costs are roughly equal, give preference to condition with a
higher percentage of likely failures.

With or Expressions, Place Terms Likely to Pass Earlier

Whenever you use the or operator, place the condition that is most likely to succeed earliest in compound expres-
sions.

Avoid Repeated Method Calls Within an Algorithm

Calling a method repeatedly to obtain a value often results in poor performance. As a performance best practice,
Guidewire recommends that you save the value from the first method call in a local variable. Then, use the local
variable to repeatedly test the value.
The following sample Gosu code suffers a performance problem. It calls a performance intensive method twice
to test which value the method returns.
if (policy.expensiveMethod() == "first possibility") { // first expensive call
// do something
}

else if (policy.expensiveMethod() == "second possibility") { // second expensive call

// do something else
}

Gosu Performance Best Practices 39

PolicyCenter 9.0.0 Best Practices Guide

The following modified sample code improves performance. It calls a performance intensive method once and
saves the value in a local variable. It then uses the variable twice to test which value the method returns.
var expensiveValue = policy.expensiveMethod() // Save the value of an expensive call.

if (expensiveValue == "first possibility") { // first reference to expensive result

// do something
}

else if (expensiveValue == "second possibility") { // second reference to expensive result

// do something else
}

Remove Constant Variables and Expressions from Loops

As a performance best practice, Guidewire recommends that you do not include unnecessary variables, espe-
cially ones that hold objects and entity instances, within loops.
The following sample Gosu code suffers a performance problem. The loop includes an object access expression,
period.Active, which remains unchanged throughout all iterations of the loop.
var period : PolicyPeriod

for (x in 5) {
if (x == 3 and period.Active) { // Evaulate a constant expression redunantly within a loop.
print("x == 3 on active period")
}

In the preceding example, Gosu evaluates the expression period.Active at least twice unnecessarily. The
following modified sample code improves performance.
var period : PolicyPeriod

if (period.Active) { // Evaluate a constant expression only once before a loop.

for (x in 5) {
if (x == 3) {
print("x == 3 on active period")
}
}
}

Avoid Doubly Nested Loop Constructs

Nesting a loop construct inside another often produces inefficient code or code that does not produce correct
results. As a performance best practice, Guidewire recommends that you avoid any doubly nested loop
constructs.
The following sample Gosu code attempts to find duplicate values in an array by using a for loop nested inside
another. The code is inefficient because it loops through the array five times, once for each member of the array.
It produces inappropriate results because it reports the duplicate value twice.
var array = new int[]{1, 2, 3, 4, 3} // An array with a duplicated value

for (y in array index m) { // Loop through the array

for (z in array index n) { // Nested loop through the array or each

// member in the outer loop

if (m != n and y == z) { // If current members in outer and inner

// loops differ and member values are equal
print("duplicate value: " + z) // Print a duplicate value in the array

}
}
}

The preceding sample code produces the following output.

duplicate value: 3
duplicate value: 3

40 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

The following sample Gosu code is a better solution. The code is more efficient because it loops through the
array once only. It produces appropriate results because it reports the duplicate value once only.
var array = new int[]{1, 2, 3, 4, 3} // An array with a duplicated value
var hashSet = new java.util.HashSet() // Declare an empty hash set, which prohibits
// duplicate values

for (y in array) // Loop through the array

if (!hashSet.add(y)) { // If array value cannot be added
// to the hash set
print("duplicate value: " + y) // Print a duplicate value in the array

The preceding sample code produces the following output.

duplicate value: 3

Pull Up Multiple Performance Intensive Method Calls

As a performance best practice, Guidewire recommends a technique called pulling up. With the pulling up tech-
nique, you examine your existing code to uncover performance intensive method calls that occur in multiple,
lower-level methods. If you identify such a method call, pull it up into the higher level-method, so you call it
only once. Cache the result in a local variable. Then, call the lower-level methods, and pass the result that you
cached down to the lower-level methods as a context variable.
The following sample Gosu code suffers a performance problem. It pushes an expensive method call down to the
lower-level routines, so the code repeats the expensive call three times.
function computeSomething() { // Performance suffers with an expensive call pushed down.

computeA()
computeB()
computeC()
}

function computeA() {
var expensiveResult = expensiveCall() // Make the expensive call once.
//do A stuff on expensiveResult
}

function computeB() {
var expensiveResult = expensiveCall() // Make the same expensive call twice.
//do B stuff on expensiveResult
}

function computeC() {
var expensiveResult = expensiveCall() // Make the same expensive call three times.
//do C stuff on expensiveResult
}

The following modified sample code improves performance. It pulls the expensive method call up to the main
routine, which calls it once. Then, it passes the cached result down to the lower-level routines, as a context vari-
able.
function computeSomething() { // Performance improves with an expensive call pulled up.

var expensiveResult = expensiveCall() // Make the expensive call only once.

computeA(expensiveResult)
computeB(expensiveResult)
computeC(expensiveResult)
}

function computeA(expensiveResult : ExpensiveResult) { // Use the pushed down result.

//do A stuff on expensiveResult
}

function computeB(expensiveResult : ExpensiveResult) { // Use the pushed down result.

//do B stuff on expensiveResult
}

function computeC(expensiveResult : ExpensiveResult) { // Use the pushed down result.

//do C stuff on expensiveResult
}

Gosu Performance Best Practices 41

PolicyCenter 9.0.0 Best Practices Guide

Be Wary of Dot Notation with Object Access Paths

As a performance best practice, Guidewire recommends that you be aware of the performance impact of dot
notation to access instance arrays on object access paths. You can write an object access path quickly, but your
code at runtime can run extremely slowly.
The following sample Gosu code suffers a performance problem. It acquires an array of addresses for all addi-
tional interests for all vehicles on the Personal Auto line of business.
var personalAutoLine = PersonalAutoLine
var personalAutoAddresses = personalAutoLine.Vehicles.AdditionalInterests.Addresses

Most likely this was not what the developer intended. Determine the most efficient means of acquiring just the
data that you need. For example, rewrite the preceding example to use a query builder expression that fetches a
more focused set of addresses from the application database.
For more general information, see “Query Builder APIs” on page 127 in the Gosu Reference Guide.

Avoid Code that Incidentally Queries the Database

As a performance best practice, Guidewire recommends that you avoid object property access or method calls
that potentially query the relational database.

Accessing Entity Arrays Does Not Incidentally Query the Database

The following sample Gosu code accesses an array of Vehicle instances as entity array.
policyLine.Vehicles // Accessing an entity array does not query the database.

Accessing the entity array does not incidentally query the relational database. The application database caches
them whenever it loads a parent entity from the relational database.

Accessing Finder Arrays Incidentally Queries the Database

The following sample Gosu code accesses an array of Policy entities by using a Finder method on a Policy
instance.
policy.Finder.findLocalPoliciesForAccount(account) // Accessing a finder array queries the database.

Calling a Finder method does incidentally query the relational database. However, the application database does
not cache finder arrays. Only your code keeps the array in memory.
To avoid repeated, redundant calls that incidentally query the database, Guidewire recommends as a best practice
that you cache the results once in a local array variable. Then, pass the local array variable to lower level routines
to operate on the same results. This design approach is an example of pulling up. For more information, see “Pull
Up Multiple Performance Intensive Method Calls” on page 41.

Use Comparison Methods to Filter Queries

The relational database that supports PolicyCenter filters the results of a query much more efficiently than your
own Gosu code, because it avoids loading unnecessary data into the application server. As a performance best
practice, Guidewire recommends that you filter your queries with comparisons methods rather than filter the
results with your own code.
The following sample Gosu code suffers a performance problem. It inadvertently loads most of the claims, along
with their policies, from the relational database. Then, the code iterates the loaded claims and their policies and
process only those few that match a specific policy. In other words, the code loads an excessive amount of data
unnecessarily and takes an excessive amount of time to search for a few instances to process.
var targetPolicy : Policy
var claimQuery = Query.make(Claim) // Performance suffers because the query loads all claims.

for (claim in claimQuery.select()) {

if (claim.Policy == targetPolicy) { // Local Gosu code filters claims.

42 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

// Do something on claims of targeted policies.

...
}
}

The following modified sample Gosu code improves performance. It finds only relevant policies to process with
the compare method:
var targetPolicy : Policy
var claimQuery = Query.make(Claim) // Performance improves because the query loads few claims.

claimQuery.compare("policy", Equals, targetPolicy) // Query comparison method filters claims.

for (claim.Policy in query.select()) {

// Do something on claims of targeted policies.
}

Use Comparison Methods Instead of the Where Method

As a performance best practice, Guidewire recommends that you always use comparison methods on query
objects made with the query builder APIs. Never convert a query builder result object to a collection and then use
the where method on the collection to specify the criteria for the query result. PolicyCenter applies comparison
methods whenever a query executes, and the database returns only qualifying entity instances to the application.
Without any comparison methods, converting a query result to a collection loads all instances of the primary
entity type into the application cache. The where method on the collection then creates a second collection with
the qualifying instances.

Comparison Methods Example

The following sample Gosu code queries the database for addresses in the city of Chicago by using a compare
method on the query object. The select object returns only Chicago addresses from the database. The database
executes the query at the time the code calls the iterator method.
uses gw.api.database.Query

var queryObject = Query.make(Address) // Create a query object.

queryObject.compare(Address#City, Equals, "Chicago") // Apply qualifying, where-clause, criteria.

var selectObject = queryObject.select() // Convert the query object to a select object.

var resultIterator = selectObject.iterator() // Convert the select object to an iterator object,

// which causes the query to be executed
// in the database.

for (address in resultIterator) { // Iterate the the qualifying addresses in result object.
print (address.AddressLine1 + ", " + address.City + ", " + address.PostalCode)

The preceding sample code performs efficiently, because the database selects the Chicago addresses. The sample
code also uses the application cache efficiently, because it loads only the Chicago addresses into application
memory.

The Where Method Example

In contrast to a comparison method on a query object, the where method on a collection performs less efficiently
and is highly inefficient in its use of application memory. For example, the following sample Gosu code queries
the database for all addresses because it omits comparison methods on the query object. The code then converts
the result object, with all addresses, to a collection. Finally, the code calls the where method on the collection to
create a second collection with only addresses in the city of Chicago.
uses gw.api.database.Query

var resultContainer = Query.make(Address).select().toCollection().where( // Fetch all addresses into

// a collection and make
\ elt -> elt.City == "Chicago" // another collection with
) // qualifying addresses.

Use Comparison Methods Instead of the Where Method 43

PolicyCenter 9.0.0 Best Practices Guide

for (address in resultContainer ) { // Iterate the second container with the qualifying addresses.
print (address.AddressLine1 + ", " + address.City + ", " + address.PostalCode)

Returning all addresses to the application uses the cache inefficiently by loading it with unwanted addresses.
Converting the result to a collection uses the application heap inefficiently by loading the collection with
unwanted addressees. Calling the where method on the collection to select only addresses in Chicago performs
the selection much less efficiently than the database.

Use Count Properties on Query Builder Results and Find Queries

As a performance best practice, Guidewire recommends that you obtain counts of items fetched from the applica-
tion database by using the Count properties on query builder result objects. The same recommendation applies to
find expression query objects. Do not iterate result or query objects to obtain a count.

IMPORTANT Guidewire recommends the query builder APIs instead of find expressions to fetch
items from the application database whenever possible, especially for new code. For more information,
see “Query Builder APIs” on page 127 in the Gosu Reference Guide.

Use Count Properties If You Want the Number Found

The following sample Gosu code uses the Count property on a query builder API result object.
uses gw.api.database.Query

var policyPeriodQuery = Query.make(PolicyPeriod) // Find all policy periods.

var result = policyPeriodQuery.select()
print("Number of policy periods: " + result.Count)

The following sample Gosu code uses the Count property on a find expression query object.
var policyPeriodQuery = find(p in PolicyPeriod) // Find all policy periods.
print("Number of policy periods: " + policyPeriodQuery.Count)

Use Empty Properties If You Want to Know whether Anything Was Found

If you want to know only whether a result or query object fetched anything from the application database, use the
Empty property instead of the Count property. The value of the Empty property returns to your Gosu code faster,
because the evaluation stops as soon as it counts at least one fetched item. In contrast, the value of the Count
property returns to your Gosu only after counting all fetched items.
The following sample Gosu code uses the Count property on a query builder API result object.
uses gw.api.database.Query

var policyPeriodQuery = Query.make(PolicyPeriod) // Find all policy periods.

var result = policyPeriodQuery.select()

if (result.Empty) { // Does the result fetch anything?

print ("Nothing found.")
}
else {
print ("Got some!")
}

The following sample Gosu code uses the Count property on a find expression query object.
var policyPeriodQuery = find(p in PolicyPeriod) // Find all policy periods.

if (policyPeriodQuery.Empty) { // Did the query fetch anything?

print ("Nothing found.")
}
else {
print ("Got some!")
}

44 Chapter 4: Gosu Language Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Use Activity Pattern Codes Instead of Public IDs in Comparisons

As a performance best practice, Guidewire recommends that you always use activity pattern codes
(Activity.Pattern.Code) in comparison expressions for conditional processing and in queries. Comparisons of
activity patterns by codes frequently avoid database reads to evaluate the expression.
The following sample Gosu code suffers a performance problem. The comparison with Activity.Pattern by
public ID cc:12345 always requires a database read to evaluate the expression.
if (Activity.ActivityPattern == ActivityPattern("cc:12345")) { // Comparisons of activity pattern
// public IDs always require a
} // database read.

The following sample Gosu code improves performance by comparing Activity.Pattern.Code with an activity
pattern code in the conditional expression.
if (Activity.ActivityPattern.Code == "MyActivityPatternCode") { // Comparisons of activity pattern
... // codes generally avoid a
} // database read.

Never localize activity pattern codes. These codes are intended for use in Gosu expressions, not for display in
error messages of the application user interface.

See also
• To learn how to add a column of localized pattern codes to the ActivityPattern entity type, see “Localized
Columns in Entities” on page 63 in the Globalization Guide.

Do Not Instantiate Plugins for Every Execution

As a performance best practice, Guidewire recommends that you do not instantiate plugins for every execution of
code that needs to call them. Plugins are reusable classes that you can instantiate once within application scope
and reuse if needed.
The following sample Gosu code suffers a potential performance problem. It instantiates a plugin within local
scope, so the plugin must initialize itself for every execution of the code that calls it.
var XPRPlugin = new com.acme.pc.webservices.plugin.VehiclePlugin() // low performance

The following modified sample code improves performance. It instantiates the plugin within application scope,
so the plugin must initialize itself only once, regardless of the number of executions of code that call it.
static var XPRPlugin = new com.acme.pc.webservices.plugin.VehiclePlugin() // higher performance

The following modified sample code improves performance even more.

var XPRPlugin = new com.acme.pc.webservices.plugin.VehiclePlugin()
gw.api.web.Scopes.getApplication().put("XPRPlugin", XPRPlugin) // highest performance

Gosu Best Practices Checklist

Use the following checklist before you complete your Gosu coding tasks to assure your Gosu code follows
Guidewire best practices.

Best Practice to Follow Best Practice Followed

Naming and Declaration Best Practices

“Observe General Gosu Naming Conventions” on page 28

“Omit Type Specifications with Variable Initialization” on page 28

“Add a Suffix to Functions and Classes to Avoid Name Conflicts” on page 28

“Declare Functions Private Unless Absolutely Necessary” on page 28

“Use Public Properties Instead of Public Variables” on page 28

Gosu Best Practices Checklist 45

PolicyCenter 9.0.0 Best Practices Guide

Best Practice to Follow Best Practice Followed

“Do Not Declare Static Scope for Mutable Variables” on page 29

“Use Extensions to Add Functions to Entities” on page 29

“Match Capitalization of Types, Keywords, and Symbols” on page 29

Commenting Best Practice

“Comment Placement” on page 30

“Block Comments” on page 30

“Javadoc Comments” on page 31

“Single-line Comments” on page 31

“Trailing Comments” on page 31

“Using Comment Delimiters to Disable Code” on page 31

Coding Best Practices

“Use Whitespace Effectively” on page 32

“Use Parentheses Effectively” on page 32

“Use Curly Braces Effectively” on page 32

“Program Defensively Against Conditions that Can Fail” on page 33

“Omit Semicolons as Statement Delimiters” on page 34

“Use != Instead of <> as the Inequality Operator” on page 35

“Observe Null Safety with Equality Operators” on page 35

“Use typeis Expressions for Automatic Downcasting” on page 35

“Observe Loop Control Best Practices” on page 36

“Return from Functions as Early as Possible” on page 37

“Use Query Builder APIs instead of Find Expressions in New Code” on page 38

Performance Best Practices

“Use the Fastest Technique for String Concatenation” on page 38

“Consider the Order of Terms in Compound Expressions” on page 39

“Avoid Repeated Method Calls Within an Algorithm” on page 39

“Remove Constant Variables and Expressions from Loops” on page 40

“Avoid Doubly Nested Loop Constructs” on page 40

“Pull Up Multiple Performance Intensive Method Calls” on page 41

“Be Wary of Dot Notation with Object Access Paths” on page 42

“Avoid Code that Incidentally Queries the Database” on page 42

“Use Comparison Methods to Filter Queries” on page 42

“Use Comparison Methods Instead of the Where Method” on page 43

“Use Count Properties on Query Builder Results and Find Queries” on page 44

“Use Activity Pattern Codes Instead of Public IDs in Comparisons” on page 45

“Do Not Instantiate Plugins for Every Execution” on page 45

46 Chapter 4: Gosu Language Best Practices

chapter 5

Upgrade Best Practices

An upgrade of your PolicyCenter installation comprises automated and manual procedures. The ways in which
your configure your PolicyCenter installation help determine the ease or difficulty of the procedures for future
upgrades.
This topic includes:
• “Upgradability Best Practices” on page 47
• “Upgrade Best Practices Checklist” on page 49

See also
• “Planning Your PolicyCenter Upgrade” on page 11 in the Upgrade Guide

Upgradability Best Practices

Guidewire recommends a number of best practices to help prepare your PolicyCenter installation for future
upgrades.
• “Add Minor Changes Directly to Base Files” on page 47
• “Copy Base Files to Add Major Changes” on page 48
• “Copy Base Functions to Make Major Changes” on page 48
• “Switching From Minor to Major Changes” on page 48

Add Minor Changes Directly to Base Files

Whenever you make only minor changes to a file, make them directly within the base file. If the file changes in a
future release, you can accept or reject the changes during the upgrade. Your changes and the changes in the new
release are visible side-by-side within your three-way merge tool while you merge the upgrade code manually.

Upgrade Best Practices 47

PolicyCenter 9.0.0 Best Practices Guide

Copy Base Files to Add Major Changes

Whenever you make major changes to a file, make a copy of the file. Name the copy of file the same as the orig-
inal, with the customer identifier inserted. For example, make a copy of SomeBaseScreenDV.pcf and give it the
name SomeBaseScreen_ExtDV.pcf.
In the original file, add a comment at the top that states you copied the file to make major changes, and include
the filename of the copy. For example:
<!-- This file was copied to SomeBaseScreen_ExtDV.pcf -->

If the file changes in a future release, you will notice that the file was copied. You then can decide whether to
replicate the changes in the new file in your copy of the base version of the file. Especially if the change
enhances the base file or fixes a defect, you may want to apply the same changes to your copy of the file.

Copy Base Functions to Make Major Changes

Whenever you make major changes to a function, or method, defined in a Gosu class, make a copy of the func-
tion and place it in a customer class. Give the copy of the function the same name as the original, with the
customer identifier as a suffix. For example, make a copy of SomeBaseFunction in a folder within your customer
package, such as com.Customername. Name the copied function SomeBaseFunction_Ext.
In the original function, add a comment at the top that states you copied the function to make major changes. For
example:
// -- This function was copied to SomeBaseFunction_Ext --

To confirm that you changed all existing code to use your copied function, temporarily rename the original func-
tion and then compile your entire project to check for compilation errors. After you remove all calls to the orig-
inal function, consider commenting out the original function to prevent developers in the future from using it
accidentally.
If the function changes in a future release, you will notice that the function was copied. You then can decide
whether to replicate the changes in your copy of the base function. Especially if the change enhances the function
or fixes a defect, you may want to apply the same changes to your copy of the function.

Switching From Minor to Major Changes

After you make minor changes to a file or function, you might decide to make additional major changes to the
same file or function. If you switch from making minor changes to making major changes, switch from the
recommendations for minor changes to the recommendations for major changes.
1. Rename the base file or function by including the customer identifier.
For example, make a copy of SomeBaseScreenDV.pcf and give it the name SomeBaseScreen_ExtDV.pcf.
2. Restore the original base file from base.zip or from your source code repository.

3. Add a comment to the top of the restored base file or function to state that the file or function was copied.
For example:
<!-- This file was copied to SomeBaseScreen_ExtDV.pcf -->

4. Make your additional major changes to the copy of the file or function.

48 Chapter 5: Upgrade Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Upgrade Best Practices Checklist

Use the following checklist before you complete your configuration of the base PolicyCenter installation to help
ease future upgrades.

Best Practice to Follow Best Practice Was Followed

“Add Minor Changes Directly to Base Files” on page 47

“Copy Base Files to Add Major Changes” on page 48

“Copy Base Functions to Make Major Changes” on page 48

“Switching From Minor to Major Changes” on page 48

Upgrade Best Practices Checklist 49

PolicyCenter 9.0.0 Best Practices Guide

50 Chapter 5: Upgrade Best Practices

chapter 6

Rating Management Best Practices

Guidewire Rating Management provides a set of tools to manage and maintain rating in PolicyCenter. Guidewire
recommends a number of best practices for Rating Management.

IMPORTANT To determine whether your Guidewire PolicyCenter license agreement includes

Guidewire Rating Management, contact your Guidewire sales representative. Rating Management
requires an additional license key. For instructions on obtaining and installing this key, contact your
Guidewire support representative.

This topic includes:

• “Rating Management Component Naming Conventions Best Practices” on page 51
• “Rate Book Edition Naming Conventions Best Practices” on page 53
• “Rate Routine Step Naming Conventions Best Practices” on page 53
• “Rating Management Best Practices Checklist” on page 53

See also
• “Rating Management Concepts” on page 559 in the Application Guide
• “Configuring Rating Management” on page 583 in the Configuration Guide

Rating Management Component Naming Conventions Best Practices

Guidewire recommends a number of naming best practices for Rating Management components. Naming
conventions are intended to provide consistency, and make it easier to identify components by line of business
and purpose.

Rating Management Best Practices 51

PolicyCenter 9.0.0 Best Practices Guide

Component names are not required to be unique, but the identifying code must be unique. For easy identification,
Guidewire recommends that you use the same value for both component name and code.

Rating Management
component Naming convention Example

Rate book PackageName + DescriptiveName PAStandardCA – Standard for Personal

Auto in California
Rate routine PackageName + DescriptiveName + _rr PAAssignDriver_rr

Rate table PackageName + DescriptiveName + _VersionNumber PACoverageBaseRate

PACoverageBaseRate_v2
Parameter set PackageName + DescriptiveName PAVehicleStandardSet

Package Name
Follow these conventions for policy line package name:
• Use capital letters, such as CP or PA for Commercial Property or Personal Auto policy lines, respectively.
• If the rating component applies to all lines of business, use ALL.

Descriptive Name
Follow these general naming conventions for DescriptiveName:
• Use mixed case with the first letter of each word capitalized.
• Do not use spaces.

Rate Books
For DescriptiveName:
• If you have multiple rate books per policy line, then add underwriting company, jurisdiction, or offering
codes to differentiate the books.
• It is not necessary to append the words book or rate book.

Rate Routine
Append _rr to easily identify rate routine codes as distinct from rate table codes.
For DescriptiveName:
• For a rate routine that calculates premium for a specific coverage, use the coverage code.
For example, a rate routine that calculates premium for Comprehensive coverage (PAComprehensiveCov is
the code) on a Personal Auto policy can be named: PAComprehensiveCov_rr.
• If a coverage has different rate routines that calculate premium for different types of risks, append the risk
type to the rate routine names. To use fewer characters, you can abbreviate the risk type.
For example, a rate routine that calculates premium for Collision coverage for occasional drivers (abbreviate
to OD) in a Personal Auto policy can be named: PACollisionOD_rr. The default rate routine for Collision cov-
erage can be named: PACollision_rr.
• If a rate routine applies to multiple coverages, then create a descriptive name. The name can be based on the
covered object. Add the word Coverages at the end.
For example, a rate routine that calculates premium for certain coverages with a covered object of
PersonalVehicle can be named: PAPersonalVehicleCoverages_rr.

Rate Table
In DescriptiveName, do not include the word table. When doing a rate table lookup in a rate routine,
PolicyCenter displays table: before the name.

52 Chapter 6: Rating Management Best Practices

 PolicyCenter 9.0.0 Best Practices Guide

Rate tables do not have a version field. However, you can copy a rate table and create the equivalent of a new
version by including a version number in the name and code.
If you plan on versioning, then use a versioning identifier as a suffix. This can be a version number or additional
information that helps you identify the version, such as _v2 or _ISO2015. You can choose to add a version
number beginning with the second version.

Rate Book Edition Naming Conventions Best Practices

The rate book edition groups a specific set of rate table versions. The rate book edition must be unique for that
rate book. For the edition, you can use any sequence or numbering scheme that you prefer.
For example:
• A series of numbers starting at 1 to be consistent with other Rating Management numbering schemes, such as
rate routine versions.
• Date in YYYMMDD format such as 20130101.
• Filing identifier such as CA-2012-39A.

Rate Routine Step Naming Conventions Best Practices

Observe these naming conventions for the instruction and operand types used in rate routine steps.
• Variables – Follow naming conventions for Gosu variable names as described in “Gosu Naming and Declara-
tion Best Practices” on page 27.
• Data model – Objects in the data model, including Cost objects follow naming conventions as described in
“Observe General Entity Naming Conventions” on page 11. If you add new objects, follow these entity
naming conventions.
• Functions – Follow naming conventions for Gosu function names as described in “Gosu Naming and Decla-
ration Best Practices” on page 27.

Rating Management Best Practices Checklist

Use the following checklist before you complete your rating management configuration tasks to ensure that your
implementation of rating management follows Guidewire best practices.

Best Practice to Follow Best Practice Was Followed

“Rating Management Component Naming Conventions Best Practices” on page 51

“Rate Book Edition Naming Conventions Best Practices” on page 53
“Rate Routine Step Naming Conventions Best Practices” on page 53

Rate Book Edition Naming Conventions Best Practices 53

PolicyCenter 9.0.0 Best Practices Guide

54 Chapter 6: Rating Management Best Practices