-
Notifications
You must be signed in to change notification settings - Fork 51
Naming conventions for member enums #7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, |
Hi Frederic, I opened this issue so that we can discuss about this before going for any change to the code. Paolo |
Right. |
Hi @fpistm
With the RTC_ prefix used by the core and no prefix for member enums. |
In the core, LSI_CLOCK (and other) is not linked to RTC and can be used by other drivers. |
What about something like this? // example definitions in the STM32 Core
typedef enum {
LSI_CLOCK,
HSI_CLOCK,
LSE_CLOCK,
HSE_CLOCK
} sourceClock_t; // (from "clock.h", no changes)
typedef enum {
HOUR_FORMAT_12,
HOUR_FORMAT_24
} hourFormat_t; // (from "rtc.h", no changes)
typedef enum {
HOUR_AM,
HOUR_PM
} hourAM_PM_t; // (from "rtc.h", added HOUR_ prefix)
// example of re-use in the libraries
class STM32RTC {
public:
STM32RTC() {}
enum RTC_Source_Clock: uint8_t
{
LSI_CLOCK = ::LSI_CLOCK,
LSE_CLOCK = ::LSE_CLOCK,
HSE_CLOCK = ::HSE_CLOCK
}; // (removed the RTC_ prefix)
enum RTC_Hour_Format : uint8_t
{
HOUR_12 = HOUR_FORMAT_12,
HOUR_24 = HOUR_FORMAT_24
}; // (removed the RTC_ prefix)
enum RTC_AM_PM : uint8_t
{
AM = HOUR_AM,
PM = HOUR_PM
}; // (removed the RTC_ prefix)
}; When invoked they would look like: // (verbose version)
int a = STM32RTC::AM;
int b = STM32RTC::LSE_CLOCK;
int c = STM32RTC::HOUR_24;
// (short version)
STM32RTC rtc;
int d = rtc.LSI_CLOCK;
int e = rtc.PM;
int f = rtc.HOUR_12; (see http://coliru.stacked-crooked.com/a/7fdd1f096be5d2d0 for a test compilation) For global identifiers defined in the core which are already quite specific, such as LSE_CLOCK or HOUR_FORMAT_12, adding another prefix might not be justified. It would not improve possible name clash issues significantly, as they are already unlikely to happen. For very short and generic global identifiers such as AM/PM, instead, adding some prefix might be beneficial. For enumerations defined as class members, having yet another prefix does not add any value and it may be removed. This might be a good compromise, not requiring a large set of changes, at least to address this kind of issue only for the RTC driver/library. It does, however, require changes in both places: core driver and the library. There might be similar "issues" in other drivers/libraries and it may be worth to review them, but maybe it's not necessary to have them all in the same commit, so they can be addressed later. What do you think? |
Seems promising.
|
Remove redundant RTC_ prefix. Fix stm32duino#7 Require Core version higher than 1.3.0 Signed-off-by: Frederic.Pillon <[email protected]>
Remove redundant RTC_ prefix. Fix stm32duino#7 Require Core version higher than 1.3.0 Signed-off-by: Frederic.Pillon <[email protected]>
Hi @ppescher
become
Could you review it and tell me if you are ok? |
Hi @fpistm |
The library forces you to write code like this (verbose):
rtc.setClockSource(STM32RTC::RTC_LSE_CLOCK);
Or this (shorter, but still redundant):
rtc.setClockSource(rtc.RTC_LSE_CLOCK);
Since the enum is already defined inside the class, we don't really need (nor we want) to type another
RTC_
prefix!Instead, the RTC driver inside the core defines about the same enums at the global scope, without any prefix. Take for example:
I think those identifiers are way too generic to be at global scope without any prefix.
If you really want to re-define enums as members of the RTC class, I think the naming convention should be swapped: global enums get the
RTC_
prefix, while member enums don't (like in early versions of the library).This issue is more general and it is present in other drivers, such as "clock.h", that live in the "stm32" subdirectory of the core. Since this is part of the include chain, all those identifiers are always in the global namespace.
If you don't like prefixes, then maybe you should use some sort of namespace dedicated to the STM32 port, but that would require to use C++ source files (which Arduino core already does by the way).
The text was updated successfully, but these errors were encountered: