PeopleCode Variable Names

A PeopleCode variable naming convention should be part of your development standards.

All variables should be declared and scoped (Global, Component or Local). Undeclared variables are included in PeopleCode validation, so if all variables are meant to be declared and you get an error show one or more variables that aren't, this may be due to a typo or other error - very handy.

Basic Data Types:

Data Type Prefix Example
Array a &aUsers
Boolean b &bEnabled
Date d &dStart
Date/Time dt &dtTimeStamp
Float f &fPercent
Integer i &iIterator
Number n &nAmount
Object o &oSession
String s &sText
Time t &tStart

Objects of Delivered Classes:

Class Prefix Example
Field fld &fldPrcsInstance
Record rec &recPrcsRequest
Row row &rowPrcsRequest
Rowset rs &rsPrcsRequest
AnalyticGrid agrd &agrdData
Chart cht &chtData
Grid grd &grdResults
GridColumn grdc &grdcSequence
Page page &pageTest
Cookie cookie &cookieData
Request rqst &rqstSent
Response rsp &rspReceived
AESection aest &aestMain
AnalyticInstance ai &aiValue
Crypt crypt &cryptHash
Exception exc &excFault
File file &fileLog
Interlink ilnk &ilnkLDAP
BIDocs bid &bidReport
JavaObject j &jSystem
Message msg &msgPublished
MCFIMInfo mcf &mcfData
OptEngine oe &oeTest
PostReport prpt &prptData
ProcessRequest pr &prSysAudit
RowsetCache rsc &rscPrcsRequest
SoapDoc soap &soapXML
SQL sql &sqlDelPrcs
SyncServer sync &syncData
TransFormData td &tdXML
XMLDoc xmld &xmldTest
XMLNote xmln &xmlnTop

Variables should be prefixed by their type (lowercase), followed by one-two words to describe what the variable is for using camel case (no word separator space, dash, underscore or otherwise).

For example, say you had a variable to store the value of the process instance. This convention dictates that process instance is either an integer or a number - lets use integer. To be descriptive we could use camel case to call this ProcessInstance, however, to shorten things lets use PrcsInstance (the field name used in the PSPRCSRQST table). So by convention I would call this field:

  • &iPrcsInstance

There's absolutely no reason why you have to follow this convention.

Someting you could add to your naming convention is scope (global, component, local):

  • &g_iPrcsInstance for a global integer
  • &c_iPrcsInstance for a component integer
  • &iPrcsInstance for a local integer (no local prefix needed)

You might want to use three letter prefix instead of one letter prefixes for the simple data types (e.g. str instead of s) but I don't see the need. Remember one of the biggest deterants from using a naming convention is complexity. If it takes too much work to use it, then guess what - it won't be used!

You may be asking why you need to use a convention at all?

Well because good code is self-documenting. Code should tell you how and comments should tell you why.

Take a look at this extremely simple example of how variable names help document your code:

If &val = 9 Then
    &result = true;
End-If;

Any idea what the code above is for? You might say you don't have enough information from that snippet. So you would then have to go looking around in the supporting code.

But what if this code actually looked this:

If &iRunStatus = 9 Then
    &bPrcsSuccess = true;
End-If;

It should be pretty clear now that when the run status has a value of 9, then a boolean called process success is set to true - perhaps indicating that the process was successful. So there you have it, self documenting code and you didn't have to include any additional (redundant) comments to explain how the code works - that should be self evident.

Further thoughts on naming Field, Record, Row and RowSet Variables

I find it helps if variables for field, record, row and rowset variables have names that match the field or record to which they reference (where possible). However I typically convert the variable names to their equivalent camel case format.

For example:

  • The variable for the field OPRID might be called &fldOprid
  • The variable for the field RUNCNTLID might be called &fldRunCntlID
  • The variable for the record PSOPRDEFN might be called &recOprDefn (drop the PS) or &rec_OPRDEFN
  • The variable for a row in the record PSOPRDEFN might be called &rowOprDefn or &row_OPRDEFN
  • The rowset for the single reocrd PSOPRDEFN might be called &rsOprDefn or &rs_OPRDEFN

What about a multilevel rowset? For example a rowset that includes the records PSOPRDEFN (operator defnition) and PSROLEUSER (operator roles)? Well this is where this rule can no longer apply. You'll need to think of a name that is appropriately descriptive. For example &rsUserProfiles. Note that sometimes the name for the record or view you are referencing is not very descriptive. So you might change the name to give the reader a clearer understanding of the data in the rowset. For example, instead of &rsOprDefn you might choose to use &rsUsers. Remember the goal here is to make your code more readable.

Another thing you can do with multi-level rowsets is to include the scroll level.

For example:

  • PSOPRDEFN is at level 0: &rsOprDefn0
  • PSROLEUSER is at level 1: &rsRoles1

As also, these are just suggestions but hopefully you can see how adopting such a convention can help make your code easier to read.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License