Better naming consistency

[matanui159]

One thing that bugs me with this project is the lack of consistency.

You have some files like ev3_xxx (eg. ev3_button), some files like ev3xxx (eg. ev3sensor) and some files like xxx (eg. analog).
Along with this, although all the function names are camelcased some start with capital letters (eg. LcdClean) while others dont (eg. readSensor)
Finally, some functions take char's when needing a small number (eg. LcdPrintf) while others take byte's (eg. SetLedPattern) [imo. You should either use int's or enums instead of worrying over getting the smallest value possible]

This is a really great project (probably one of the best and most maintained attempts at C for native EV3 [no new OS or anything]) but I believe it should be a bit more consistent with its naming.

[a3f]

This is a side-effect of the API starting as merger of existing APIs by different authors, but it indeed would be nice to have a consistent naming scheme.

I'd suggest:

• Keep original headers to maintain API-stability, but document deprecation
• Create an ev3/ directory with non-ev3- prefixed headers
• Remove BYTE/byte/WORD … etc. types and use <stdint.h>'s [u]intN_t types
• Replace all char/byte/int object identifiers e.g. Timer in TimerReady in ev3_timer.h with enums
• Adjust old headers to use new prototypes if C promotion rules guarantee, it continues to work. If they don't, provide a macro (or static inline function) wrapper.

Source-Level compatibility is important for us, as there are university courses using the API and changing teaching materials takes time.

Off-topic, but would also benefit from a refactoring:

• Implement LcdPrintf in terms of fopencookie()
• Remove Ev3Init() and Ev3Close() Boilerplate by means of constructor and destructor __attribute__s.
• Probably more? Suggestions?

---

We'd appreciate pull requests. Are you interested in giving this a go? =)

[matanui159]

Maybe do all the above plus more as an C4EV3 v2?

I'd be happy to help where I can. I don't know to much about the behind-the-scene workings, but I could try learning.

[a3f]

I'd rather maintain a single version. I believe with a bit of care, we only have to duplicate the headers and can keep the same library code for both versions.