Skip to content

Naming Conventions

These are guidelines for picking names codes that should be followed to ease the work of code developers. Although codes that do not stick to these conventions most of the time do not create bugs this is still considered best practice.

Naming things

Everything in the database (Component Type, Test Type, Test Parameters, Component Stages, etc.) have two names:

  • Name: used in GUI to display components and overviews.
    • Upper and lower case letters and white spaces allowed
    • These should be as clear as possible for a human reader and match names given in other documentations (e.g. EDMS). They can anyway easily be changed in the future if needed.
    • The name should typically not be longer than 20 characters (to be checked, characters have different horizontal sizes) so as to not break the display in the PDB GUI. Often a description field can be used to offload details that cannot fit in the name.
  • Code: used in API code to communicate with database, must be unique and they should follow a naming convention
    • Do not use spaces, special characters, etc. Only use upper case letters, numbers and underscores.
    • These cannot be changed in the future but do not need to be as explicit as the human readable name.

Subsystem specific Component Types

Within Pixels, Component Types that are specific to a subsystem should be prefixed with their respective subsystem code:

  • Inner Pixels: IS (for Inner System)
  • Outer Pixel Barrel: OB (for Outer Barrel)
  • Pixel End-caps: OEC (for Outer End-Caps)

This prefix should be added to both the name and the code of the Component Type. Other subsystems do not have such a convention. While widely used within the Pixels community, note that these shorthands do not match the XX code of Serial Numbers.