Guidewire Best Practices Exam (QUESTIONS WITH 100% CORRECT ANSWERS ) (2024 / 2025) (Verified by Experts)

Guidewire
Best
Practices
Exam
(QUESTIONS
WITH
100%
CORRECT
ANSWERS
)
(2024
/
2025)
(Verified
by
Experts)
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
Logging
is
used
for
-
ANSWER
Application
maintenance
and
troubleshooting
Creating
statistics
relating
to
application
usage
Auditing
by
capturing
significant
events
Typical
events
to
log
are
-
ANSWER
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
-
ANSWER
has
a
category
and
level,
sends
content
to
an
Appender
Logging
components
-
Appender
-
ANSWER
is
an
output
destination
(server
console
or
rolling
file) Logging
components
-
Layout
-
ANSWER
defines
the
format
of
the
content
sent
to
an
appender
Logging
Level
-
Trace
-
ANSWER
Description:
Fine-grained
informational
events
When
to
use:
Log
method
entry
and
exit
Logging
Level
-
Debug
-
ANSWER
Description:
Detailed
informational
events
When
to
use:
Log
important
steps
and
calculations
for
diagnosing
problems
Logging
Level
-
Info
-
ANSWER
Description:
Coarse-grained
informational
messages
of
progress
When
to
use:
Log
the
occurrence
or
result
of
an
important
event
Logging
Level
-
Warn
-
ANSWER
Description:
Indicate
a
potential
problem
When
to
use:
The
user
experience
has
not
been
affected
Logging
Level
-
Error
-
ANSWER
Description
-
Indicate
definite
problems
When
to
use:
The
user
experience
has
been
affected
There
are
2
ways
to
initialize
a
logger
in
Gosu
-
ANSWER
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
-
ANSWER
a
standard
format
to
simplify
analysis
of
large
logs
Guarded
Logging
should
be
used
-
ANSWER
To
test
log
level
before
logging
costly
messages
(those
with
expensive
expressions)
Typically
used
with
the
DEBUG
level
Format
is
-
if
(_logger.DebugEnabled)
{
<log
statement
content>}
Not
required
for
parameterized
expressions
lacking
expensive
operations,
as
in:
var
hello
=
"Hello"
var
world
=
"world"
_logger.debug("{},
{}!",
hello,
world)