It certainly better that the previous example, but it's just another black box library. It either works and I learn nothing or it doesn't work and not interested in wasting more time on it. If it works now and I commit to using it and later it turns out to be worse in more ways, I end up binning the entire project.
Sticking with the HAL stuff and just writing around the bugs is probably much, much faster. That IS the point yes? The point of a HAL and other libraries is to make applications rapid to develop. That makes the platform comfortable both to hobbiests but especially to profressionals. Your boss will not take kindly to you spending 5 weeks in the datasheet to demonstrate your programming prowess when the junior engineer beside you has it done in 2 days with HAL.
At least the HAL libraries understand that code is for HUMANs. Binary is for computers. So writing things in (preferably) English and not acronym/operator soup is a good start.
Thing is HAL's coding "style" is fine in the vast majority of places. It has bugs and some of the approaches and annoying, but functionality and style are different things.
Compare that with a block, chained combination of three letter acronyms like _ACR, mathetical logic operators like | and &, but shifts with "magic numbers" and finally a few logical &&s and ||s. A single line of code with about 40 different operations mixed up it it. Great until it breaks. It's literally written in code. The code is the acronyms. It's like writing a new language were you take all the stuff that allows people to read it and even understand what it does without reading documentation. Self describing code written for humans.
Others will hate my code. I even add entire variables and functions I don't need so that it reads and explains itself well. Beside 99.9% of the "Don't do that it wastes x, y, z" are non-sense since about 1990 and modern C compilers.
That style of "compressed" "code golf" coding has no place out of nerd clubs. I'm not even joking, if code like that was submitted in a pull request in work it would be out right rejected and the person told to completely scrap it and start it again. It's absolutely useless to anyone. If it works, great, but nobody is going to know how or why in 3 weeks. It's not like you can just read it out loud to yourself and understand it. You'd need to sit down with a pen, paper, spreadheet and the datasheet for 2 or 3 weeks to have a clue what it's doing. it's pointless and will cost more time than it would cost to have it rerwitten by a different engineer. An engineer writing code like that would not survive long in team projects.
It's also historically significant, because when C and such language were in their infancy a Megabyte of harddrive space would cost you about £100,000. So making your variable names short as possible and compressing your code "text" as much as possible was the way. Nobdy cared about code being readable, just write it once, get it out the door.
This let to more than a decade of issues across the whole software industry. Problems we are STILL sloving today. It seems the embeded folks have a lot to learn as their platform expands and becoming more and more generic and code will start to hang around beyond one or two projects, you can no longer get away with that old brittle obsfucated way of programming.
A good little test. If you find yourself writing comments explaining your code. STOP! Stop right there. Delete that bit of code and rewrite it so you don't need the comment.
