#if HAS_ or #ifdef HAS_ standardisation

[S5NC]

There are 32 uses of #if HAS_[...] and 28 of #ifdef HAS_[...], we should standardise on one.
We would need to make sure #elif, #ifndef, etc. are also made uniform and #else behaviours are consistent before and after the change.

I am in favour of using #if HAS_, and having a file, as we currently do, which has the default 1 or 0 values. This alleviates the need to make HAS_[...] keywords have a polarity of the default option, and we can make all HAS_[...] names positive, so 1 clearly enables, and 0 disables that feature.

[jp-bennett]

+1 as I've recently found a minor bug resulting from an accidental ifdef HAS_.

[mrx23dot]

Definitely #if, that way compiler complains if headers are messed up.
Common mistake rookies do.

[oseiler2]

Small contribution towards this: #3733

[S5NC]

https://github.com/search?q=repo%3Ameshtastic%2Ffirmware+%22%23ifdef+HAS_%22&type=code
https://github.com/search?q=repo%3Ameshtastic%2Ffirmware+%22defined%28HAS_%22&type=code
https://github.com/search?q=repo%3Ameshtastic%2Ffirmware+%22%23ifndef+HAS_%22&type=code

I think the only place for definition checks should be in configuration.h like

#ifndef HAS_WIFI
#define HAS_WIFI 0
#endif

• Have global default behaviours, which set each HAS_[...] to 0 or 1, probably disabling all, in configuration.h
• Perhaps have default behaviours for each architecture or board?
• Each variant.h file can set the HAS_[...] they want to change
• Use #ifndef working backwards, first including variant.h, then configuration.h, because having #undefs in variant.h is a complication.