This page describes the look and feel of code as much as the HSE coding idiom. Items marked with [VI-AN] are testable with VI Analyzer

• English is the default language for

  • filenames
  • variable / control names
  • comments in code

• File names are built with spaces between words

  • No CamelCase
  • No Under_Lines
  • No Hy-phe-na-tion
• Capitalisation of everything but conjunctions, prepositions etc. (“or”, “and”, “by”, “for”…)
• Same rules apply to case labels, function names etc.

Append two dashes (--) and an identifier to the file name of special VI and Control types, eg Something--constant.vi or Another Thing--cluster.ctl.

• Use System style controls for VIs with User Interfaces (enable in Options → Front Panel → Control Style for New VIs)

  • Modern style is an acceptable fallback for SubVIs

• Terminals of controls and indicators are not to be displayed as icons on the blockdiagram [VI-AN]

  • Right mouse click on icon → uncheck „View As Icon“
  • „Tools – Options → Block Diagram → General“ uncheck option „Place front panel terminals as icons“

• Disable Auto Grow, make space manually by Ctrl-dragging instead

  • „Tools – Options → Block Diagram → General“ uncheck option “Place structures with Auto Grow enabled”

• Use and connect error cluster [VI-AN]

  • Connector Pattern bottom left & right
  • No unexpected behavior should go unnoticed!
  • Make not wiring an error out the exception, and document why it's unwired

• Move error wires to background [VI-AN]

  • QD shortcut for moving to back: Ctrl-shift-J

• Use VI Connector Pattern default (4-2-2-4) [VI-AN]

  • Exception: 1 In, 1 Out → „flat“ Icons

• Connector terminals default to “required” (enable in Options → Front Panel → General)

• Size of front panel / block diagram [VI-AN]

  • doesn't exceed the display (one monitor size)
  • if scrolling is necessary: only in one direction (horizontally or vertically)

• Follow the dataflow paradigm [VI-AN]

  • Don't use local variables where you can use wires
  • Sequential processing of SubVIs by connecting the Error in- and outputs
  • Stacked sequence structures „hide“ code and are to be avoided

• Conditional Disable Symbols case sensitivity

  • True value is spelled TRUE (all uppercase)
  • False value is spelled FALSE (all uppercase)

• Optional: For case structures, if the value wired to the case selector from the outside is NOT used inside the case structure, move the case selector near the top in the middle of the subdiagram label. This will symbolize that the wire is not connected inside the cases

• For case structures of type String, enable the “Case Insensitive Match” option unless explicitly required otherwise

• Use Compound Arithmetic instead of boolean logic gates

• Do NOT use invert options on boolean functions and operators

  • use a separate not operator instead to increase readability

• For integer values, always select i32 unless another type is explicitly required

• Units in Square Brackets: Append units in square brackets [ ] to the variable name.

  • Examples: distance[km], time[s], temperature[°C].
• Standard Units: Use SI units where possible. Non-SI units must be consistent and documented.

  • Examples: force[N], speed[km/h].
• No Unit: Use [-] if the variable is unitless.

  • Example: scalingFactor[-].
  • Special Note: If the variable represents a fraction (e.g., a ratio), where the value ranges from 0 to 1 without explicit scaling use [-]. If a variable represents a percantage use [%] instead.
• No Redundancy: Do not repeat units in both the variable name and value.

  • Correct: distance[km] = 50
  • Incorrect: distance_km = 50 km.

• Keep cohesion high and coupling low

  • Collect resources that belong together in a library or class
  • If a VI, library or class has “and” in its name (or should have “and” in its name), split it up!

• Do not use Auto-Populating Folders

  • Code needs to live in either LabVIEW libraries (.lvlib) or LabVIEW classes (.lvclass) (see above)
  • Auto-populating would show subfolders as empty virtual folders outside the lvlib/lvclass
  • Unused files on disk would be pulled into the project automatically and not show up in dependencies where we could find and investigate them

• Use Auto-Populating Folders only:

  • while cleaning projects and looking for orphaned files
  • for resource or configuration folders

    • never for source code
    • never for DLLs or other dependencies

• Each .lvproj file may only contain one (1) target with VIs underneath

  • A project for Windows applications or Windows libraries may only have VIs under the “My Computer” target!
  • A project for a real-time application may only have a single target with VIs under it, and must not have any (!) VIs under the “My Computer” target or any other targets (exception: FPGA)!
  • See Unclear error messages during RT Deployment for the reasons behind this rule

• See SCC Rules for how to handle .lvproj files with source code control