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.

[awneil]

You are clearly not a UNIX fan, then!

This is an argument that has been running - and will continue to run - forever amongst software developers & computer scientists.

haacked.com/.../

At the end of the day, it is just a matter of personal style/preference.

[Jarmo]

A nice article.

A matter of style, partially yes. If you prefer deep (slow) learning curve then choose abbreviations, but preferring easy starting puts you choose clear wording.

[awneil]

As you said, I see your point - but don't agree.

[Jarmo]

Yep. As a kid, I might have agreed with you, since I quickly learned all the needed magic words to program ZX-81, VIC-20, Commodore 64, Amiga etc (and actually, also Unix). Nowadays, it is much harder to learn to memorize new programming language details, and I need google a lot. On the other hand, the programming vocabularity is also much higher, today.

[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