Guidewire Best Practices Exam study guide

Avoid using internal path for your classes - wire.* 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 re 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: ntication 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