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 &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