Added log ids to logs #84

New Issue

MrUnknownDE · 2026-04-05T17:51:48+02:00

MrUnknownDE commented

2026-04-05 17:51:48 +02:00

Originally created by @gorbit99 on 5/8/2025

This PR attempts to implement #226, but is currently very work-in-progress and exists as more of a starting point than a final draft.

Each module of the code, besides getting the prefix, also gets an identifier, usually a lowercase version of its name, like "sensormanager" or "battery" or "fs", etc etc. Each module then has a list of numbers corresponding to one or a few messages all falling within the same narrow category, for example, the "Handshake successful, server is ..." message gets the unique HandshakeSuccessful id (connection-5), but anything that's manual calibration related would likely get the CalibrationInstruction id (sensor-9).

The format is then as follows:

{connection-5} [UPDConnection] [DEBUG] Handshake is successful, server is ...

The benefits of this technique:

Everything is specified, nothing is up to chance or code generation
"Collisions" are only possible if the programmer messes up, which are easy to notice
Changing texts around has no effect on the ids
The format string is still visible and is where it's used

And the cons:

Everything needs to be manually set up
If it's necessary to separate out a bunch of lines uniquely, that will be a lot of enum values

There are a couple other ways to go about this, in particular

Creating either pairs of a format string and an id then referencing that instead
Keeping all the strings used in the project in a single file then referencing them by ID

For several reasons I didn't like either of those options, so I went with this one instead.

*Originally created by @gorbit99 on 5/8/2025* This PR attempts to implement #226, but is currently very work-in-progress and exists as more of a starting point than a final draft. Each module of the code, besides getting the prefix, also gets an identifier, usually a lowercase version of its name, like "sensormanager" or "battery" or "fs", etc etc. Each module then has a list of numbers corresponding to one or a few messages all falling within the same narrow category, for example, the "Handshake successful, server is ..." message gets the unique HandshakeSuccessful id (connection-5), but anything that's manual calibration related would likely get the CalibrationInstruction id (sensor-9). The format is then as follows: ``` {connection-5} [UPDConnection] [DEBUG] Handshake is successful, server is ... ``` The benefits of this technique: - Everything is specified, nothing is up to chance or code generation - "Collisions" are only possible if the programmer messes up, which are easy to notice - Changing texts around has no effect on the ids - The format string is still visible and is where it's used And the cons: - Everything needs to be manually set up - If it's necessary to separate out a bunch of lines uniquely, that will be a lot of enum values There are a couple other ways to go about this, in particular - Creating either pairs of a format string and an id then referencing that instead - Keeping all the strings used in the project in a single file then referencing them by ID For several reasons I didn't like either of those options, so I went with this one instead.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/SlimeVR-Tracker-ESP#84