Inhalte

• Home
  • License Agreement
  • Introduction
  • IDE Settings
  • Project
  • Repository
  • Comments
  • reStructuredText
  • Naming
  • Formatting
    • Formatting Structured Text and Extended Structured Text ExST
    • Formatting SFC
  • Practices
    • Practices Introduction
    • Common Practices
      • Common Practices Interfaces
      • Common Practices Data Structures vs Objects
      • Common Practices Inheritance
      • Common Practices Dependencies
        • Common Practices Dependencies Examples
          • Common Practices Dependencies Examples Dependency Injection
            • Dependency Injection Introduction
            • Dependency Injection Common Interfaces
            • Dependency Injection Devices
            • Dependency Injection Inter-Stopper-Communication
            • Dependency Injection Stopper Workflows
            • Dependency Injection Stopper
            • Dependency Injection Declaration in Main
            • Dependency Injection Summary
          • Dependencies Examples Abstract Factories
            • Abstract Factories Introduction
            • Abstract Factories Object
            • Abstract Factories Alarm Messages
            • Abstract Factories Alarm Message Service
              • Alarm Message Service Introduction
              • Alarm Message Service Common Interfaces
              • Alarm Message Service Collection Interfaces
              • Alarm Message Service Factories
              • Alarm Message Service Collection Implementations
              • Alarm Message Service Alarm Message Distributor
            • Abstract Factories OPC-UA HMI Connection
            • Abstract Factories Test it
            • Abstract Factories Summary
      • Common Practices ControlStatus Words
      • Common Practices Scope Pointer
      • Common Practices Divide The Libraries
      • Common Practices Return Values
    • STExST Practices
      • STExST Practices GOTO JMP
      • STExST Practices CASE OF
      • STExST Practices Assignment as Expression
      • STExST Practices Namespace Alias
      • STExST Practices VAR_OUTPUT
    • SFC Practices
      • SFC Practices Jumps
      • SFC Practices Cyclic Rotations
  • Glossary
    • Glossary A
    • Glossary B
    • Glossary C
      • Glossary Class
    • Glossary D
      • Glossary Data Transfer Object
      • Glossary Dto
    • Glossary E
    • Glossary F
      • Glossary Foo
    • Glossary G
    • Glossary H
    • Glossary I
    • Glossary J
    • Glossary K
    • Glossary L
    • Glossary M
    • Glossary N
    • Glossary O
    • Glossary P
    • Glossary Q
    • Glossary R
    • Glossary S
    • Glossary T
    • Glossary U
    • Glossary V
    • Glossary W
    • Glossary X
    • Glossary Y
    • Glossary Z

Naming

Table of Contents

Common

Names are used everywhere in software, and the names are important for the readability and the searchability. Finding good names takes time, but it saves more than it takes. Take care with the naming and if you find better ones don’t be shy and use the refactoring to change it. However, we have some rules for the naming.

Inputs

• All boolean inputs must always start with the prefix 'DI_' the name is capitalized and always describes the high active state, for example DI_EStopIsOk or for a light barrier DI_LightBarrierIsFree. In the case of signals, e.g., a sensor signal that is masked in a sensor class, a High Active name may not be possible. Here the name should be chosen so that it is clear that the signal is processed further, such as DI_RawSensorSignal.

• All numeric inputs must always start with the prefix 'AI_' the name is capitalized, for example AI_AirPressure or AI_StatusWord.

Outputs

• All boolean outputs must always start with the prefix 'DO_' the name is capitalized and always describes the high active state, for example DO_InterlockIsOk or DO_MoveCylinder2HomePos. In the case of signals, e.g., a valve signal that is masked in a cylinder class for a cylinder with an output only, a high active name may not be possible. Here, the name should be decided so that it is clear that the signal is processed further, such as DO_RawValveSignal.

• All numeric outputs must always start with the prefix 'AO_' the name is capitalized, for example AO_PressureSetPoint or AO_ControlWord.

Tasks

• All tasks must be capitalized and must have the same name as the called program, except when a task has more than one callee, then the name should reflect what the group of callees is for, like PlcTasks or VisionTasks.

Interfaces

• All interface names must begin with an uppercase 'I' prefix, followed by a capitalized name.

• The name of the interface must be an adjective, noun, or noun phrase. For example: IComparable, ICylinder, or IServoAxis.

• It is also acceptable to use declarative phrases that begin with "I Can", such as ICanStop or ICanRun.

• The interface name should be derived from the client’s usage to ensure clarity and relevance.

• Implementation details must not appear in the name of an interface. The name should strictly represent the role or capability of the interface, not how it is implemented.

• When using interfaces, the camel case convention must be followed, and no prefix should be added. The variable name should reflect the interface being implemented. For example:
  pressCylinder : ICylinder;.

Classes (function blocks)

• All class names must be capitalized without any prefix, the class names should be never ever a verb, and must be always a noun or a noun phrase like Dispatcher or CylinderWith2Outputs2Inputs.

Methods

• All method names must be camel cased without any prefix, the method names should be never ever a noun, and must be always a verb or a verb phrase like store or moveToHomePosition. The method names should only describe what is done, but not how it’s done.

Actions

• All action names must be camel cased without any prefix, the action names should be never ever a noun, and must be always a verb or a verb phrase like stopor pressBolt. Action names should only describe what is done, but not how it’s done.

Properties

• All property names must be camel cased without any prefix, the name has to reflect what the property stands for like velocitySetpoint or actualVelocity.

Functions

• All function names must be capitalized without any prefix, the function names should be not a noun, but a verb phrase like CalculateCircleArea. Function names should only describe what is done, but not how it’s done.

Programs

• all program names must be capitalized without any prefix, the names should be not a verb, but a noun or noun phrase like PressStation40 or MainTask.

Structs

• All struct names must be capitalized without any prefix, the struct names should be never ever a verb, and must be always a noun or a noun phrase like Recipe or ProductTrackingData. Members must be camel cased without any prefix, and must reflect what the member stands for, like recipe.wireFeedVelocityInMMPerSecond.

Types (alias)

• All type names must be capitalized without any prefix, the name has to reflect what the type is used for, like MessageBodyForLabelPrinter or SerialNumber.

Enumerations

• All enumerations must be capitalized without any prefix, the names should be not a verb, but a noun or noun phrase like PressStation40State or ProductProgress. All enumerations must be defined with the pragma {attribute 'qualified_only'}. Members (enumeration constants) must be upper cased without any prefix, phrases must use underscores to separate words, like ProductProgress.PRESSING_STARTED. The member name must reflect what it stands for, like PressStation40State.START_PRESSING. The pragmas {attribute 'strict'} and {attribute 'to_string'} are recommended, but not required.

Global variable lists

• All global variable lists must be capitalized without any prefix, the names should be not a verb, but a noun or noun phrase like Alarms or InputsStation60. All enumerations must be defined with the pragma {attribute 'qualified_only'}.

Objects

• All object names must be camel cased without any prefix, the object names should be never ever a verb, and must be always a noun or a noun phrase like conveyor or robotJobDispatcher.

Variables

• All variable names must be camel cased without any prefix, should be not a verb, but a noun or noun phrase like cylinder or trayOffset. Counter variables for iterations like i or j are commonly used, but the problem is that these are not searchable, which is why you should avoid them.

Hardware Config

• The device names in the hardware config must be the full-qualified DT (device tag) from the wiring schematic. Otherwise it is not searchable. By the way: the addressing must also be equal to the wiring schematic.

Constants

• All constant names must be upper-cased without any prefix, phrases must use underscores to separate words, like MAX_NUMBERS_OF_TRAYS.

SFC Transition objects

• All transition object names must be camel cased without any prefix, the name always describes the state of the transition when it is fulfilled, for example minimumPressingTimeIsReached.

SFC Branches

• All branch names must be camel cased, the branch name must be an unique name inside the class and must have the prefix ‘branch'. The branch names are not necessary for the readability of software, the branch names are only needed if we get merge conflicts, where they make it easier to understand the *.TcPOU file, that’s why the prefix and the unique name are required.

SFC Steps

• All step names must be camel cased without any prefix, the step names should be never ever a noun, and must be always a verb or a verb phrase like pressor movePressCylinderToHomePosition. The initial step must always be named ‘init’.

SFC Macros

• All macro names must be camel cased without any prefix, the step names should be never ever a noun, and must always be a verb phrase like sendPartData2Mes. The macro names should only describe what is done, but not how it’s done.