Guidewire Best Practices Exam study guide Questions
with Correct Answers 2025 latest update!!
Avoid using internal path for your classes - (ANSWER)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 - (ANSWER)Use TC_TYPECODE instead of "typecode",
example: LossCause.TC_REAREND instead of "rearend"
Use the text for logical operators instead of the symbols - (ANSWER)Use
"and","or", and "not" instead of "&&", "||", and "!"
Code placement - (ANSWER)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 - (ANSWER)Guidewire will
eventually remove deprecated classes and methods.
Turn on and run Studio Inspections - (ANSWER)These analyze configuration
resources
Use whitespace effectively - (ANSWER)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 - (ANSWER)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 - (ANSWER)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 - (ANSWER)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 - (ANSWER)Use UpperCamelCase
Do not add _Ext to classes within customer package spaces
Function naming conventions - (ANSWER)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 - (ANSWER)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 - (ANSWER)Add suffix _Ext too all new display
keys
Do not modify automatically generated display keys
Logging is - (ANSWER)The process of recording application actions and state to a
secondary interface
with Correct Answers 2025 latest update!!
Avoid using internal path for your classes - (ANSWER)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 - (ANSWER)Use TC_TYPECODE instead of "typecode",
example: LossCause.TC_REAREND instead of "rearend"
Use the text for logical operators instead of the symbols - (ANSWER)Use
"and","or", and "not" instead of "&&", "||", and "!"
Code placement - (ANSWER)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 - (ANSWER)Guidewire will
eventually remove deprecated classes and methods.
Turn on and run Studio Inspections - (ANSWER)These analyze configuration
resources
Use whitespace effectively - (ANSWER)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 - (ANSWER)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 - (ANSWER)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 - (ANSWER)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 - (ANSWER)Use UpperCamelCase
Do not add _Ext to classes within customer package spaces
Function naming conventions - (ANSWER)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 - (ANSWER)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 - (ANSWER)Add suffix _Ext too all new display
keys
Do not modify automatically generated display keys
Logging is - (ANSWER)The process of recording application actions and state to a
secondary interface
