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 TypePrefixExampleArraya&aUsersBooleanb&bEnabledDated&dStartDate/Timedt&dtTimeStampFloatf&fPercentIntegeri&iIteratorNumbern&nAmountObjecto&oSessionStrings&sTextTimet&tStart

Objects of Delivered Classes:

ClassPrefixExampleFieldfld&fldPrcsInstanceRecordrec&recPrcsRequestRowrow&rowPrcsRequestRowsetrs&rsPrcsRequestAnalyticGridagrd&agrdDataChartcht&chtDataGridgrd&grdResultsGridColumngrdc&grdcSequencePagepage&pageTestCookiecookie&cookieDataRequestrqst&rqstSentResponsersp&rspReceivedAESectionaest&aestMainAnalyticInstanceai&aiValueCryptcrypt&cryptHashExceptionexc&excFaultFilefile&fileLogInterlinkilnk&ilnkLDAPBIDocsbid&bidReportJavaObjectj&jSystemMessagemsg&msgPublishedMCFIMInfomcf&mcfDataOptEngineoe&oeTestPostReportprpt&prptDataProcessRequestpr&prSysAuditRowsetCachersc&rscPrcsRequestSoapDocsoap&soapXMLSQLsql&sqlDelPrcsSyncServersync&syncDataTransFormDatatd&tdXMLXMLDocxmld&xmldTestXMLNotexmln&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 &rsOprDefnyou 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