A Couple of Must-have PeopleCode Coding Standards

A Couple of Must-have PeopleCode Coding Standards

2011年10月30日 | 标签: PeopleSoft

The following are a couple of I believe not well-known coding standards for PeopleCode that I strictly adhere to. These are something I don’t see most people or teams are adapting, but something I really recommend looking into for the benefits that they offer.

1. Declaring Local Variables
2. Usage of the %Table() meta-SQL When Writing SQL Statements

I. Declaring Local Variables

 

 

Background

Except for Application Package PeopleCode, the PeopleCode compiler/editor does not require that local variables used by programs are declared. Undeclared variables are automatically allocated the type of Any.

Coding Standard

When writing PeopleCode, declare ALL local variables that will be used.

Benefits

1. Declaring the specific type of variable needed improves performance, in contrast with the interpreter always assuming a type of Any. Even if the variable to be declared requires being an Any type, declare it nonetheless (see 4th item below).
2. Compile-time validation.
   • When variables are declared, the PeopleCode editor can check the compatibility of variables used in an operation, or passed as function arguments.
   • For variables pointing to objects, the names of methods and properties can be validated at save time.
3. Convenience. For built-in buffer classes (Rowset, Row, and Record), shorthand notation is only allowed for declared variables.
4. For programming languages that allow dynamic allocation of variables, it is a common programming error to misspell variable names. However, on the PeopleCode editor, when all variables are consciously declared, it is easy to check for misspelled variable names (see the following illustration). Thus, with this standard in place, this type of coding error would be eliminated.

 

Illustration

Take a moment to look at the following PeopleCode example:

This code has 2 misspelled variables. How long did it take you to find them?

The code could be modified to enforce the rule that all variables are consciously declared; resulting in the following (changes are highlighted):

Now, when this PeopleCode is saved, or when the Validate Syntax action () is invoked. The following messages would be displayed in the Output window:

Double-clicking these messages would bring you to the offending line in the code.

NOTE: As shown in the example above, it is NOT necessary to always declare the variable at the top of the program. Declaring them on the first time they are used is sufficient to achieve the said benefits.

II. Usage of the %Table() meta-SQL When Writing SQL Statements

 

 

Background

When writing SQLExec statements, the common practice is to hard-code table/view names. For example:

 SQLExec("Select FIELD1, FIELD2 From PS_RECORD_TBL Where CRITER1 = :1 AND CRITER2 > :2", &IN1, &IN2, &OUT1, &OUT2); 

A problem with the above code is that information in the PeopleCode string literals cannot be classified by the compiler and saved into the PeopleTools reference tables.

Coding Standard

Use the meta-SQL %Table() in SQL statements to refer to SQL tables or views.

With a little effort, the above code can be transformed into the following (changes are highlighted):

 SQLExec("Select FIELD1, FIELD2 From %Table(:1) Where CRITER1 = :2 AND CRITER2 > :3", Record.RECORD_TBL, &IN1, &IN2, &OUT1, &OUT2); 

Benefits

The consequence of this change is that Record.RECORD_TBL is saved as a reference in the appropriate PeopleTools reference table (PSPCMNAME). This brings the following maintenance advantages:

1. A Find Definition Reference for RECORD_TBL record will include the above SQLExec line in the results.
2. Renaming RECORD_TBL will automatically propagate to the PeopleCode references (App Designer automation). No coding change is required.
3. For more complex SQL, like ones that need effective-dated logic, you can reference the record name only once. For example, if RECORD_TBL is effective-dated, you could write the following:

    SQLExec("Select FIELD1, FIELD2 From %Table(:1) A Where CRITER1 = :2 AND CRITER2 > :3 And EFFDT = (SELECT MAX(EFFDT) FROM %Table(:1) WHERE KEY1 = A.KEY1 AND EFFDT <= %CurrentDateIn)", Record.RECORD_TBL, &IN1, &IN2, &OUT1, &OUT2); 

4. At a glance, the number of tables/views being referenced by the SQLExec can be easily identified.

 

NOTE: Unfortunately, currently the criteria parameter of the Select() method of the rowset class does not properly handle the %Table() meta-SQL, therefore this is one case where you cannot use this standard. Although fortunately, the need to reference a table in theSelect() criteria seldom happens.

Always declare variables:

&sATttVariablename

s = scope
• l=function local
• c=component
• g=global
• k=pseudo constant (generally global in scope)
• i=function parameter input variable
• o=function parameter output variable
• x=function parameter input and output variable
• p=property of an Application Class

A=indicator this is an array (not present if scalar)

Ttt=type (2 or 3 chars)
• Str=String
• Nbr=Number
• Dat=Date
• Int=integer
• Obj=Object (usually Component Interface objects)
• Rs=Rowset
• Rw=Row
• Re=Record
• Fe=Field
• Fi=File Object
• Fl=File Layout

Exceptions:

For-Loop variables and indices
• &i, &j, &k, et. seq.

Variable Names:

• When referring to identifiable underlying PeopleSoft objects, use that object name
Examples:
o Local rowset &lRsPERSONAL_DATA
o Global Record &gReJOB
o Component Date &cFeEFFDT

• For non-PeopleSoft object references, use mixed case and avoid underscores.
This helps because when coding the variables will automatically convert to mixed case if declared and referenced properly.
Examples:
o &lStrMyName
o &gDatTarget
o &cIntRecCounter
o Local array of string &gAStrMyValues;