GUIDEWIRE
Guidewire Best Practices Exam
Study Guide.
Avoid using internal path for your classes - ✔✔✔ - com.guidewire.* should be avoided. These
can always be potentially changed or replaced during an upgrade.
When referencing typecodes, use the static property on the typelist class instead of the string
representation - ✔✔✔ - Use TC_TYPECODE instead of "typecode", example:
LossCause.TC_REAREND instead of "rearend"
Use the text for logical operators instead of the symbols - ✔✔✔ - Use "and","or", and "not"
instead of "&&", "||", and "!"
Code placement - ✔✔✔ - 1) Avoid placing code within the CODE tab of a PCF. Create a UI
helper class instead
2) Avoid extending entity enhancements with code supporting UI operations
Avoid using deprecated classes and methods - ✔✔✔ - Guidewire will eventually remove
deprecated classes and methods.
Turn on and run Studio Inspections - ✔✔✔ - These analyze configuration resources
Use whitespace effectively - ✔✔✔ - Add spaces around operators
Do not add spaces between parentheses and operators
Indent logical blocks of code by two spaces only
GUIDEWIRE Page 1
,GUIDEWIRE
Add a blank line after code blocks
Add two blank lines after methods, including the last method in a class
Comments and Annotations - ✔✔✔ - Document new classes and functions with Javadoc-style
comments
Use single-line comments within functions and methods when you need to clarify the intent of
the code
Use GoseDoc annotations which are included when generating GosuDoc
"Upgrade-Safe" naming conventions: Add the suffix _Ext to - ✔✔✔ - Columns added to
existing entities
Typecodes added to existing typelists
The name of custom entities
The name of custom typelists
New PCF files
Script parameters
Package naming conventions - ✔✔✔ - Use the format
customer.application.featurecategory.feature
Customer - company name abbreviation
Application- InsuranceSuite application code (pc, bc, cc, suite)
Feature Category - major feature (delinquency, configuration, integration)
Feature - feature (rating, catastrophe, authentication)
Example: si.suite.integration.authentication
Class naming conventions - ✔✔✔ - Use UpperCamelCase
GUIDEWIRE Page 2
, GUIDEWIRE
Do not add _Ext to classes within customer package spaces
Function naming conventions - ✔✔✔ - Use lowerCamelCase
Use a verb that describes that the function is doing i.e. verifyAddress
Do not add _Ext suffix to private functions or enhancements in customer package spaces
Variable naming conventions - ✔✔✔ - Member variable names use lowerCamelCase with a
leading underscore i.e. _pluginCallbackHandler
Local variable names use lowerCamelCase short names that describe the purpose i.e.
latestPolicyRevision
Display key naming conventions - ✔✔✔ - Add suffix _Ext too all new display keys
Do not modify automatically generated display keys
Logging is - ✔✔✔ - The process of recording application actions and state to a secondary
interface
Logging is used for - ✔✔✔ - Application maintenance and troubleshooting
Creating statistics relating to application usage
Auditing by capturing significant events
Typical events to log are - ✔✔✔ - Success / Failure - a transaction or action has succeeded or
failed
Recovery - a system went down or connection failed, retried, and recovered
Identification - any large functional areas such as integration, rating, reinsurance, and rules
GUIDEWIRE Page 3
Guidewire Best Practices Exam
Study Guide.
Avoid using internal path for your classes - ✔✔✔ - com.guidewire.* should be avoided. These
can always be potentially changed or replaced during an upgrade.
When referencing typecodes, use the static property on the typelist class instead of the string
representation - ✔✔✔ - Use TC_TYPECODE instead of "typecode", example:
LossCause.TC_REAREND instead of "rearend"
Use the text for logical operators instead of the symbols - ✔✔✔ - Use "and","or", and "not"
instead of "&&", "||", and "!"
Code placement - ✔✔✔ - 1) Avoid placing code within the CODE tab of a PCF. Create a UI
helper class instead
2) Avoid extending entity enhancements with code supporting UI operations
Avoid using deprecated classes and methods - ✔✔✔ - Guidewire will eventually remove
deprecated classes and methods.
Turn on and run Studio Inspections - ✔✔✔ - These analyze configuration resources
Use whitespace effectively - ✔✔✔ - Add spaces around operators
Do not add spaces between parentheses and operators
Indent logical blocks of code by two spaces only
GUIDEWIRE Page 1
,GUIDEWIRE
Add a blank line after code blocks
Add two blank lines after methods, including the last method in a class
Comments and Annotations - ✔✔✔ - Document new classes and functions with Javadoc-style
comments
Use single-line comments within functions and methods when you need to clarify the intent of
the code
Use GoseDoc annotations which are included when generating GosuDoc
"Upgrade-Safe" naming conventions: Add the suffix _Ext to - ✔✔✔ - Columns added to
existing entities
Typecodes added to existing typelists
The name of custom entities
The name of custom typelists
New PCF files
Script parameters
Package naming conventions - ✔✔✔ - Use the format
customer.application.featurecategory.feature
Customer - company name abbreviation
Application- InsuranceSuite application code (pc, bc, cc, suite)
Feature Category - major feature (delinquency, configuration, integration)
Feature - feature (rating, catastrophe, authentication)
Example: si.suite.integration.authentication
Class naming conventions - ✔✔✔ - Use UpperCamelCase
GUIDEWIRE Page 2
, GUIDEWIRE
Do not add _Ext to classes within customer package spaces
Function naming conventions - ✔✔✔ - Use lowerCamelCase
Use a verb that describes that the function is doing i.e. verifyAddress
Do not add _Ext suffix to private functions or enhancements in customer package spaces
Variable naming conventions - ✔✔✔ - Member variable names use lowerCamelCase with a
leading underscore i.e. _pluginCallbackHandler
Local variable names use lowerCamelCase short names that describe the purpose i.e.
latestPolicyRevision
Display key naming conventions - ✔✔✔ - Add suffix _Ext too all new display keys
Do not modify automatically generated display keys
Logging is - ✔✔✔ - The process of recording application actions and state to a secondary
interface
Logging is used for - ✔✔✔ - Application maintenance and troubleshooting
Creating statistics relating to application usage
Auditing by capturing significant events
Typical events to log are - ✔✔✔ - Success / Failure - a transaction or action has succeeded or
failed
Recovery - a system went down or connection failed, retried, and recovered
Identification - any large functional areas such as integration, rating, reinsurance, and rules
GUIDEWIRE Page 3
