Coding Standards

PCB Repositories

This standard should be reviewed and formalized in a more organized manner, but for now, this is a list of requirements off the top of my head. Feel free to argue for or against any of these points, and reach out if you have ideas for more.

• General Rules

  • All code is organized into the appropriate folders, in alignment with the project template's format

  • No commented code is left in place without justification

  • A copy of the datasheet of each chip used on a board should be put into the datasheets folder of the repository

• Targets

  • All targets have a comment at the top explaining what they're for

  • Main Targets

    • Handle all hardware-specific initialization

    • Have a main loop that contains only a call to the PCB class's `process()` function and necessary CANopen calls

    • Have no calls to `uart.printf()`, only `log()` statments

• Classes

  • All classes have Doxygen-formatted comments summarizing their purpose

  • All functions have Doxygen-formatted comments explaining their use

  • All variables have Doxygen-formatted comments explaining their purpose

  • For a constructor, whatever can be handled by an initializer list, should be

  • PCB Classes

    • Hold no references to specific hardware

      • For the time being, classes should have a a few constant `IO::Pin`s to list all the pins used on the actual hardware

        • We are currently investigating better ways to handle this

    • Expose only a constructor and `process()` method to other classes

This list is by no means exhaustive, so you'll need to use your own discretion to some degree. Be sure to discuss your thoughts on how to improve our code quality with other members of the team.

Database Repositories