How is device control software checked for quality?
I've worked on some certified software in a different domain (and slightly less strict); the principle would be similar here.

Basically the certifying authority will want to make sure that proper risk analysis was done on the system—both software and hardware—and risks were mitigated to get to certain level of reliability.

The authority does not have programmers to actually review the code. They will be checking the requirements, the test coverage, records that all procedures were followed. All code must be traceable to requirements that caused it to be written, tests that cover it, there must be records it was reviewed, that all the tests passed.  All requirements must have their tests, then there have to be various stress tests, exploratory tests, the test plans have to be reviewed. There will be various static checks too and guidelines to follow. It is a massive amount of paperwork to make sure risks were not missed.

And then the required estimated mean time between failures for critical systems is so insanely low—IIRC for critical systems the mean time between critical failures must be (estimated) at least 10⁹ hours—that there is simply no way to demonstrate it by tests alone. Even the hardware won't have that reliability—it is hundred thousand years. So the system has to be designed so that it can fail safe and fail over to a backup and then the mean time between failure of all the systems during single flight is what gets above the target.

So there is procedure, but the maker does it and the certification authority only verifies that it was followed.

The safety critical code is indeed usually written in C, or sometimes C++ or Ada. However, safety critical, and any other hard real-time, code must be written with use of static memory only. This eliminates large class of problems that C code is normally known for, and the simplicity of C makes it easier to statically check—and the makers of critical software have powerful advanced tools for doing it—, so it is actually quite good fit.

The code still actually tends to be pretty ugly. It is hammered heavily with the tests, but when fixing issues found, preference is to do smaller changes to avoid breaking other parts that already passed the tests, which adds to its ugliness. Nobody thinks its perfect either, but that's not the point. The hardware is not perfect either, so the backups, fail-safes and fail-overs are designed to handle both kinds of failures.

And note that the current Boeing issue is actually a problem with the requirements. The trim system may run away for example if the switch gets stuck, which is always a risk with mechanical switch, so there must be a cut-off switch to disconnect it. And, judging from the public information only, it seems whoever designed this system argued that that cut-off switch is sufficient to handle failure of the new addition too, so the system was not considered critical and fault detection was not included in the requirements for it. But in doing so they apparently underestimated the human factors involved—specific details will be subject to analysis in the investigation and it is what usually takes so long.



Update: The article about the recent B38M crash (ET-302) links to an FAA document FAA and Industry Guide to Product Certification that gives overview of the whole process. It is not particularly about software, but the general process still applies to that.