This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

About nRF SDK naming conventions

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.

  • 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.

  • 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.

Related