#SensorManager variable names
1 messages ยท Page 1 of 1 (latest)
In most cases they reflect the sensor's ID. For sensors that include sensor in the ID, would you propose renaming it to [x]SensorSensor?
no, I'm not proposing that ๐
I just suggest to have a naming like it's shown on the right side of the screenshot
Right but wouldn't that be more inconsistent than it is right now?
To answer your original question: I'm not confused by it, there aren't many static variables in the sensor managers
(Not opposed to it but it should be consistent)
Maybe others have a different opinion ๐
Currently, activeNotificationCount doesn't represent the "number of active notifications" (="active notification count"), but rather the "sensor measuring the count of active notifications", that's why I'm suggesting naming it activeNotificationCountSensor
but maybe we're not on the same page how we understand this
Could provide an example for your standpoint? It would help me understanding it ๐
I am all for consistency here, naming can be hard ๐
If the app needs to count the number of active notifications, it probably wouldn't be in the companion object but instead be a local variable in the function for the sensor update?
For most sensors the companion object doesn't hold a persistent state
In this case the variable name shows the sensor ID active_notification_count -> activeNotificationCount, but there are others like pressure_sensor -> pressureSensor
I found an instance of my suggestion: dndSensor: https://github.com/home-assistant/android/blob/aaef43ae386661f236593e207fb3279397bbd453/app/src/main/java/io/homeassistant/companion/android/sensors/DNDSensorManager.kt#L16
And there's at least 1 more like this, but it's still the minority.
There are also sensors that don't match the ID or include Sensor ๐
So I don't really see the point? In most cases, if you access a variable from the companion object it is the sensor. The names are already inconsistent and I don't feel like adding Sensor at the end would improve that.