About nRF SDK naming conventions

[Jarmo]

Being a person with a poor name memory, I am really frustrated with the nRF SDK's naming conventions. For example, let's take a function

bsp_btn_ble_on_ble_evt()

Is that a descriptive name, eh? Every time I hit a function name, or symbol, like that one, I have to (re-)check what actually was its purpose. Instead, wIth good naming conventions, all that frustrating document and code browsing work could be avoided and huge amount of time would be saved.

If you really care about your customers and easiness of programming with your great hardware, you could start from the very basic things. Use descriptive names in your code, please.

[ovrebekk]

Hi Jarmo

Good function naming is a challenge, and it is very hard to find a set of rules that works great in all circumstances.

When it comes to the use of underscore vs camelcase then underscores is by far the most common in the industry for C code, and is used by standards such as Misra C or K&R. Camel case is more common in object oriented languages such as C++ and Java, and all our Android examples use camel case.

The reason for using abbreviations is to shorten the function names. Our internal guide lines put limits both on the length of function names, and on entire code lines, to avoid having to scroll to the right when reading code. While having long and descriptive names might help to understand that particular function the first time you read it, it will make it harder to get an overview of the code, since you have to break up code lines to avoid them being too long.

We also have a requirement to prefix all function names with the name of the module, which means the module name should be as short as possible to avoid breaking the function name length limit.

As I said in the start all naming conventions have pro's and cons. In the end we try our best to ensure that we are consistent within the Nordic libraries, and that we follow industry standard as much as possible without needlessly reinventing the wheel.

Best regards
Torbjørn

[Jarmo]

Thank you for your answer and the time! I do understand that having consistent rules that do not change when "the game is already running" are important for that kind of large software process.

Well. I am not sure what's actually wrong with the SDK, but everything feels too hard and complicated. Making an application takes two to ten times the time needed to implement same thing with Arduino code. I have written code for nRF5 now over two years, about ten to twenty different kind of customer projects.

After not being able to adopt the thinking behind your SDK, I eventually started to write an extra software layer hiding all that nRF-SDK complexity. For me, it looks like the SDK is written with an approach "we've got a hardware, let's write the software". Instead, what I would look for is to first think what a programmer really needs, and write the API from that point of view.

[ovrebekk]

Thanks for the input Jarmo.

Being a hardware company you are probably correct that many of the drivers are written "from the bottom up" ;) We want the software drivers to be as flexible as possible, and support all the hardware features available, which makes them more complex than needed for many customers.

We do support alternative software stacks, such as mBed or Arduino, if people want more intuitive API's, but the SDK will always be the place to go if you need more flexibility or need to get new features faster.