Gdyby obiektywnie popatrzeć na oprogramowanie, które tworzyłem - nawet
te większe, latami rozwijane przez wiele osób systemy - to napisany
kod, jakkolwiek by mierzyć jego rozmiar, jest jakimś nieszczęsnym
ułamkiem całej infrastruktury. Malutkim zbiorem…

Testing with “100% code coverage” doesn’t work: Unit Test Tools like VectorCAST can give you code coverage statistics, cyclomatic complexity, and paths exercised in Unit Testing, but that’s NO GUARANTEE your test actually exercised the code under all possible in-the-wild conditions. I can easily get 100% code coverage, yet the code does not work? Why? Because 100% code coverage only says that every line of code must be covered which is different from every code path. Even though the lines of code were “covered”, the result of the test may not have been dependent upon that path. Let’s say you got 100% code coverage via two tests: One test covers paths A and B. Test two covers C. That’s considered “100% code coverage” as it’s defined by unit test tools, yet the path A->B->C was never tested nor were any significant permutations of that. Furthermore, the test result of your Unit Test may have resulted in the same answer regardless of the existence of an error in that “covered” path. These are all situations I have run into.

My point is this: it’s impossible to catch every bug in an embedded program and perfection has never happened and does not exist. It’s really the lead engineer’s job to mitigate the risk of misbehaving code at a higher level. Coders are usually working mindlessly to higher level design. Here’s how I mitigate bad coding:

Rule #1: No loops. All code must be in the form of an FSM (finite state machine) with a WATCHDOG TIMER for each state.
Rule #2: No dynamic memory allocation. Screw what you learned in Computer Science. All structures must be static or global.

Rule #1 eliminates the possibility of the program hanging from infinite loops. (Zune problem)
Rule #2 eliminates the possibility of crashing due to overflow or null pointer.

Embedded C is far different from C programming. This industry isn’t about making code fast and efficient. It’s about making it manageable so that if bugs are discovered they can be found. All of the suggestions to make this code more concise would just make bugs more difficult to find. Verbose and explicit coding may seem juvenile to people still in school, but that’s the way people expect you to code in the real world. No one cares that you can write code in one line what might take an idiot 10 lines of code to accomplish. The byte code will look identical because of compiler optimizations.

for (year = ORIGINYEAR; days >= daysInYear(year); year++)
days -= daysInYear(year);

where daysInYear(int year) = (IsLeapYear(year) ? 366 : 365)

I haven’t tried it and for all I care to check it might not even work, but at least it is very easy to verify that the routine will eventually complete in all cases.

I always thought that void SomeMethod(int x, int y) is already a big disaster. The person who wants SomeMethod has to specify 2E+128 outcomes that he wants. So I have given up a long time ago about wanting to work in General Dynamics.

The people who do not forgive the Zune bug are simply armchair critics. I can bet they will be most unwilling to pay $20,000,000 for an MP3 player.