Ask HN: Why is code from chip manufacturers of such a low standard?
I have had the unfortunate to work with a lot of C code from chip manufacturers such as ST, Microchip(Atmel), Bosch, Semtech. More often then not the code quality is rather low[0], sometimes even embarrassing. Perhaps I am just unlucky and only seen the bad parts, but it seems like a good business plan to provide a decent driver/library before spending a single dollar on marketing? Or at a minimum, have a experienced programmer review what is released as "official" to avoid shaming the company name.
Can anyone explain this?
[0] To avoid offending anyone I do not want to link repos, but here are some examples of "low code quality":
- Libraries that looks like internal test code renamed and pushed to github.
- Using bit-fields for registers. Well, it will probably work even though it is implementation defined. It is however a strong indicator the programmer(s) are relative new to C which manifest itself in all kinds of other issues. Can anyone explain this? Are you asking if companies make bad reference code a deliberate part of their product? I don't think any company will admit to that if it was their plan. I've seen just as much bad code as you - probably more. My observations come down to this: 1) It's reference code and labelled as such, so there's no warranty and thus no investment in making the code look good, follow any standard, or even be readable. If it works, that's enough. 150 out of 150 unit tests pass? End of story. Complaining to your FSE will get you either a shrug or a quote from their contact engineering arm. Better FSEs at better companies will try to get to the original author and ask them what the hell is up. 2) The code is written by the hardware engineers writing the Verilog and designing other parts of the chip. Sometimes they're using it to validate the part and sometimes they're recruited to write the reference code and sometimes it's both but, in all cases, they're typically not software engineers. 3) The code is shopped out to contract software engineers in far away time zones because of cost. Any companion software has a non-zero cost which means it has to be paid for in the price of the chip sooner or later. There's a strong drive to keep that cost down, obviously. I get your frustration and it would be nice if you could port reference drivers into your project in two clicks and then get back to finishing your sprint. I feel fortunate if there's anything I can read alongside the datasheet. I could mention companies that I think do better than others, but that will probably attract a flurry of counterexamples. From my POV it's just part of the job. Interesting!
Perhaps I should have phrased the question better,
I do not think it is deliberate, but I still do not understand why code quality have such a low priority . Software development is expensive so it seems to me it would be a market advantage to provide more decent drivers and examples. I also suspect some new designs are never realized due to bad vendor code - seems like a missed sale opportunity. It all comes down to what a chipmaker is willing to spend to get that sale. Some manufacturers do prioritize good software and I do see that they benefit from that in the long run. I also suspect some new designs are never realized due to bad vendor code - seems like a missed sale opportunity. A very astute observation. Why not start a hardware company and seize that opportunity?