[Ffmpeg-devel] compiler warnings

Steve Lhomme steve.lhomme
Thu Mar 30 10:10:06 CEST 2006

M?ns Rullg?rd wrote:
> Steve Lhomme <steve.lhomme at free.fr> writes:
>> Having to guess exactly how a C compiler process data to know exactly
>> what is does is bad engineering. Even though the code is correct and
>> small, it makes it harder to read by a large number of coders. Making
>> the code easily readable is important to maintain the code, not wonder
>> if the compiler has to be C90 or C99 or whatever to compile a line
>> correctly.
> Code should be made easy to read for those who will actually read it,
> not necessarily for every school kid with a computer.  Competent
> programmers find the kind of code Rich advocates easier to read.

I have been in many companies (as a contractor) and noone ever asked me 
if I could debug a compiler. And having a code in a company that only a 
few select developers can work with (those with the experience usually 
end up managing projects, not coding) is a very bad habit. Especially 
given the turn-over for programmers is very high. That means the code 
will end up being unmaintained, removed or rewritten. Another example of 
bad engineering.

>> That's why the famous quote from here "fix the compiler" is also not
>> realistic in the real world. Most of the time you are given a compiler
>> (and an IDE) that goes with the hardware you're working with (I'm not
>> talking about PCs) and you just do with it. You'll just get fired if
>> instead of fixing bugs you were saying your boss "it's not my fault,
>> it's the compiler". It's an engineering practice that will get you
>> nowhere.
> I get away with it all the time at my day job.  Common phrases there
> are things like "it's a driver bug", "it's the compiler's fault",
> "it's a bug in some-component-not-under-our-team", followed by "we'll
> just have to wait for them to fix it".

I guess they are paying you to find problems, not solutions.


More information about the ffmpeg-devel mailing list