This article describes the standards that apply to procedure and function names. All of the listed recommendations are mandatory unless noted otherwise.
1. Proper naming of procedures and functions is very important because it makes the code easier to read. In most cases, a good procedure name combined with properly selected parameter names will eliminate any need to further describe the procedure. In some situations, difficulties in selecting names for a procedure and/or its parameters reveal poor programming code architecture. The opposite is also true: if it is easy to come up with a "self-documenting" name, then the procedure has been properly designed.
2. Parameters, functions, and formal parameters should be named based on the terms of the subject area so that the name makes the purpose clear. Try to make the names "self-describing".See also: Procedure and function descriptions
Incorrect:
Function Check(Parameter1, Attr, TS) Function GetAttributeArrays(BusinessTransaction, AllAttributesArray, TransactionAttributesArray)
Correct:
Function SpecifiedObjectTypeAttribute(Object, AttributeName, ValueType) Function FillAttributeNamesByBusinessOperation(BusinessOperation, AllAttributeNames, OperationAttributeNames)
3. Names should be generated by deleting spaces that separate the words. Note that every word in the name should then be capitalized. Prepositions and pronouns that consist of a single letter are also capitalized.
This recommendation is optional 4. We recommended that you do not describe the types of accepted parameters and/or returned values in procedure and function names. Incorrect: Function GetArrayOfRolesWithAddRight() Function GetAggitionalSettingsStructure() Correct: Function NamesOfRolesWithAddRight() Function AdditionalSettings() This recommendation works in the majority of situations, with only a few exceptions when, without the type of returned value, the purpose of the procedure or function itself is not clear. 5. In general, procedure names should be based on the infinitive of the verb specifying the essence of the action they execute. Incorrect: Procedure CounterpartyLoading() Correct: Procedure LoadCounterparty() 6.1. In general, function names should be based on a description of the returned value. Incorrect: Function GetFullUserName() Function CreateVendorPriceFillingParameters() Function DefineSessionStartDate() Correct: Function FullUserName() Function NewVendorPriceFillingParameters() Function SessionStartDate() 6.2. If a function is intended to create an object, we recommend using "New" in its name. Incorrect: Function AddFormField() Function CreateFilesCatalogItem() Function GetCommandTable() Correct: Function NewFormField() Function NewFilesCatalogItem() Function NewCommandTable() 6.3. If a function checks a particular condition, we recommend beginning its name with "Is" or using participle II. Incorrect: Function CheckIfDocumentIsPosted() Function CheckIfDocumentAttributesChanged() Function ExternalTask() Correct: Function DocumentPosted() Function DocumentAttributedModified() Function IsExternalTask() 6.4. We recommend using infinitives in function names when one must know how the returned value was produced in order to understand the function’s purpose. Examples: Function SelectDataByRule(Rule, UserSettings) Function ConvertDataByRule(DataSets, ConversionParameters) 6.5. If executing a function first of all involves performing an action, and returning a value is not its main purpose (e.g. it serves to show that an action has been successfully executed), such functions should be named based on infinitives, and the same is true for procedures. Example: Function AllowEditingObjectAttributes(Form) |
Next page: Procedure and function parameters