#SensorManager variable names

1 messages ยท Page 1 of 1 (latest)

wheat dagger
#

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?

twin cargo
#

no, I'm not proposing that ๐Ÿ˜„

#

I just suggest to have a naming like it's shown on the right side of the screenshot

wheat dagger
#

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 ๐Ÿ™‚

twin cargo
#

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 ๐Ÿ™‚

oak mountain
#

I am all for consistency here, naming can be hard ๐Ÿ˜›

wheat dagger
#

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

twin cargo
#

And there's at least 1 more like this, but it's still the minority.

wheat dagger
#

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.