7.3 Source File Naming [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 7.3 Source File Naming ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:07-naming-and-file-conventions:start | Return to Naming and File Conventions ]]

Source file names should indicate the file's implementation responsibility. A developer should be able to distinguish [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] implementation files, shared support files, [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] helpers, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] readers, status publishers, command handlers, and test support files from their names and locations.

The team should follow the naming conventions of the selected implementation language where those conventions are strong and widely understood. For example, Java classes, C++ source files, Python modules, and JavaScript or TypeScript modules may use different idiomatic file-naming conventions. The handbook should not impose a single style across all languages when the language ecosystem already provides a clear convention.

Source files should avoid generic names such as:

  * ''helper''
  * ''utils''
  * ''misc''
  * ''test''
  * ''main''
  * ''new''
  * ''old''
  * ''final''

If the team uses a generic support file, the name should still identify its role, such as:

  * ''nodeStatusPublisher''
  * ''nodeCommandHandler''
  * ''configurationLoader''
  * ''controlPlaneTopicNames''

Source file names should not include temporary version labels such as ''v2'', ''new'', ''old'', ''backup'', or ''final-final''. Git provides version history. File names should identify the current purpose, not editing history.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>