Naming Conventions

Article • 05.08.2022 • 3 minute(s) to read

This article and its entire content are awaiting approval and will be released soon. You can get support for custom app development by asking questions in the forum; most questions get answered fairly quickly. Please do not use the contact form or private messages for technical support questions about building custom apps with the Novunex Platform.

Following a consistent set of naming conventions in the configuration of a Novunex app can significantly contribute to the app’s usability. It allows the app to be used by many developers on widely separated projects. Beyond consistency of form, names of Novunex configuration elements must be easily understood and convey each element’s function.

Identifiers

This section aims to provide a consistent set of naming conventions resulting in names that Novunex developers easily understand. The following best practices apply to all identifiers used in the Novunex Platform.

Examples for identifiers

  • Attribute names
  • Entity Type names
  • Variable or process context names

Out-of-scope examples

  • The naming of Processes or Activities
  • Names of Dashboards or Views
  • Any identifier that is presented via the UI to the end-user

Do not apply identifier naming conventions to text that is shown to end-users. A platform developer enjoys easily readable and understandable variables. However, end-users are not used to this terminology and prefer commonly understood descriptions of interfaces. E.g., do not apply pascal casing to labels or headlines.

Capitalization Rules for Identifiers

Identifiers used in the Novunex Platform follow the PascalCase. To differentiate words in an identifier, capitalize the first letter of each word in the identifier. Do not use underscores _ (e.g., snake_case) or hyphens - (e.g., kebab-case) to differentiate words anywhere in identifiers.

PascalCasing Convention

The PascalCasing convention, used for all identifiers, capitalizes the first character of each word (including acronyms over two letters in length), as shown in the following examples:

  • AttributeName
  • TcpPacket
  • TimezoneUtc
  • IOStream (special case for two-letter acronyms)

Boolean Identifiers and Terms

For variables or identifiers in general, use the positive case instead the negative case description. In addition, use verbs to create unambiguous attribute meanings.

Do Do not
IsComplete Completion, IsIncomplete
IsFaulted IsUnFaulted
IsReady IsNotReady
IsSuccessful Successful, IsUnsuccessful
HasProblems Problems, HasNoProblems

Capitalizing Compound Words and Common Terms

Compound terms are treated as single words; therefore, each word in a so-called closed form must not be capitalized. These are compound words written as a single word, such as endpoint.

Do Do not
SignOut signOut
TimeZone timeZone
Email EMail, eMail
UserName userName, Username
Writeable writeAble, WriteAble

Word Choice and Abbreviations

Choose easily readable identifier names. For example, an attribute in an Entity Type named ModificationDate is more English-readable than DateOfModification or DateModified. Always favor readability over length or abbreviations. Write CanStartDevice instead of StartDev or StartableDEV. Avoid abbreviations when possible, even though they are well known in your industry.


More information

  • About the design guidelines