
Ask HN: Why is code from chip manufacturers of such a low standard? - sorisos
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&#x2F;library before spending a single dollar on marketing?
Or at a minimum, have a experienced programmer review what is released as &quot;official&quot; to avoid shaming the company name.<p>Can anyone explain this?<p>[0] To avoid offending anyone I do not want to link repos, but here are some examples of &quot;low code quality&quot;:<p>- Libraries that looks like internal test code renamed and pushed to github.<p>- 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.
======
joezydeco
_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.

~~~
sorisos
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.

~~~
joezydeco
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?

