Naming conventions for methods

Method naming

Write a clear, descriptive name for your method or function. If one cannot be found, consider splitting it up.

Use the following preferred names for methods:

Name

Description

check*

A Boolean method that checks a condition. If the condition is not fulfilled, it must put a warning on the Infolog, and return false.

exist

Returns a Boolean that is true if a record with the supplied key exists.

Typical use: Table static method.

find

Returns a record indicated by the supplied key.

Typical use: Table static method.

find*

Finds a record in the table (where the method is declared). The postfix is the name of the field which is used for accessing the table, or a logical name for more fields.

Typical use: Table static method.

initFromTableName

This buffer is initialized with values from the buffer supplied.

One argument, which is a buffer of the same type as that named in the method.

Typical use: Table instance method.

initParm

Used for methods that set member variables. If the method only sets some of the variables, indicate this in a prefix to the name, for example initParmVersDate.

is*

A Boolean method that will check some condition. If the condition is not fulfilled, it must return false. is* cannot change the method. Information must not be sent to the Infolog.

parmMemberVariableName

Methods used for setting and getting the value of a member variable as a part of an object initialization. The method should have the same name as the variable, prefixed with parm.

get*

Used for methods that get value(s) from the object. The name must make it clear that the method also gets the state of some other global members.

set*

Used for methods that set value(s) in the object. The name must make it clear that the method also sets the state of some other global members. set* methods should be void or Boolean, signaling the result of the set.

updateFieldName

createFieldName

If a method updates or creates a record, reflect that in the name, rather than calling the method set FieldName.

validate*

Same as check*.

Methods that have the names listed in the preceding table must carry out the tasks described, and must not have any additional functionality. For example, there must be no assignments in a validate, check*, or is* method.

Use of suffixes

Methods on the new tables are created without suffix (as table should has it).

Examples:

Tables\ItemCategoryList_PRJ\Methods\initItemCategoryListId()
Tables\EcoResProductDivision_PRJ\Methods\find()

Methods on the existing tables are created with help of class extensions also with suffix.
See also Extending tables.

Examples for how they could be called:

ecoResCategory.setCategoryGroupId_PRJ();
inventTable\validateItemConsumerGroup_PRJ();

Existing methods calling

Calling of existing methods (including system functions) should use same casing as method defined.

Follow IntelliSence suggestions in case of doubts.

Example (incorrect):

INFO(Enum2Str(NoYes::NO));

Example (correct):

info(strLTrim(strRTrim(strFmt("Hello, World"))));
salesTable.DeliveryDate = dateNull();
info(enum2Str(NoYes::No))

Use of Uppercase and Lowercase

Methods have mixed-case names with a lowercase first letter. The first letter of each internal word is capitalized.

Examples:

classDeclaration TutorialExampleClass_PRJ
{
    public void nameThisMethodCorrectly()
    {
    }


}

RunBase extensions

Mutator method must be implemented for each public parameter in class extension of RunBase*. Use prefix parm followed by full name of variable, as method-name:

Examples:

class InventABCUpdate extends RunBaseBatch
{
    FromDate fromDate;
    DialogField dialogFromDate;
    
    ToDate toDate;
    DialogField dialogToDate;
 
    public FromDate parmFromDate(FromDate _fromDate = fromDate)
    {
        fromDate = _fromDate;
        return fromDate;
    }
    
    public ToDate parmToDate(ToDate _toDate = toDate)
    {
        toDate = _toDate;
        return toDate;
    }
 
}