Guidewire Best Practices Exam Study Guide
Questions| With Complete Solutions.
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
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
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
Logging components - Logger
, has a category and level, sends content to an Appender
Logging components - Appender
is an output destination (server console or rolling file)
Logging components - Layout
defines the format of the content sent to an appender
Logging Level - Trace
Description: Fine-grained informational events
When to use: Log method entry and exit
Logging Level - Debug
Description: Detailed informational events
When to use: Log important steps and calculations for diagnosing problems
Logging Level - Info
Description: Coarse-grained informational messages of progress
When to use: Log the occurrence or result of an important event
Logging Level - Warn
Description: Indicate a potential problem
When to use: The user experience has not been affected
Logging Level - Error
Description - Indicate definite problems
When to use: The user experience has been affected
There are 2 ways to initialize a logger in Gosu
Integration: PLLoggerCategory.INTEGRATION
Plugin: PLLoggerCategory.PLUGIN
Use sub-level of existing logging category to maintain structure.
Example: PLUGIN.MotorVehicleRecord
static var _motorVehiclePluginLogger =
LoggerFactory.getLogger(PLLoggerCategory.PLUGIN."MotorVehicleRecord")
Logging Format should be
a standard format to simplify analysis of large logs
Guarded Logging should be used
Questions| With Complete Solutions.
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
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
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
Logging components - Logger
, has a category and level, sends content to an Appender
Logging components - Appender
is an output destination (server console or rolling file)
Logging components - Layout
defines the format of the content sent to an appender
Logging Level - Trace
Description: Fine-grained informational events
When to use: Log method entry and exit
Logging Level - Debug
Description: Detailed informational events
When to use: Log important steps and calculations for diagnosing problems
Logging Level - Info
Description: Coarse-grained informational messages of progress
When to use: Log the occurrence or result of an important event
Logging Level - Warn
Description: Indicate a potential problem
When to use: The user experience has not been affected
Logging Level - Error
Description - Indicate definite problems
When to use: The user experience has been affected
There are 2 ways to initialize a logger in Gosu
Integration: PLLoggerCategory.INTEGRATION
Plugin: PLLoggerCategory.PLUGIN
Use sub-level of existing logging category to maintain structure.
Example: PLUGIN.MotorVehicleRecord
static var _motorVehiclePluginLogger =
LoggerFactory.getLogger(PLLoggerCategory.PLUGIN."MotorVehicleRecord")
Logging Format should be
a standard format to simplify analysis of large logs
Guarded Logging should be used
