HomeLog InSource


[View] [Short] [Hash] [Raw]


Keywords: creative process


One of the most difficult things I’ve had to come to accept as a developer is: If you see a ‘clever’ way to solve something, STOP. The sad fact is most programmers work on programming teams and you need to absolutely view yourself as expendable. Embrace mediocrity and find another outlet for your creativity. This could be personal projects outside of the workplace, or other hobbies altogether.

I’ve seen this advice several times before, but this time it really hit me how depressing it is.

John Carmack on the importance of Static Code Analysis (altdevblogaday.com)

I went digging up this article because I’ve been thinking static analysis might be a good option for EarthFS.


Finally, I went back to PC-Lint, coupled with Visual Lint for IDE integration. In the grand unix tradition, it can be configured to do just about anything, but it isn’t very friendly, and generally doesn’t “just work”. I bought a five-pack of licenses, but it has been problematic enough that I think all the other developers that tried it gave up on it. The flexibility does have benefits – I was able to configure it to analyze all of our PS3 platform specific code, but that was a tedious bit of work.

The difference between other programmers and John Carmack? Again, depressing.

We all have our own priorities and that’s fine. What’s sad is not noticing when our actions contradict our stated goals, or not seeing how all these little choices add up.

I learned a lot going through this process. I fear that some of it may not be easily transferable, that without personally going through hundreds of reports in a short amount of time and getting that sinking feeling in the pit of your stomach over and over again, “we’re doing OK” or “it’s not so bad” will be the default responses.

I’ve slowly come to realize how whole classes of simple errors are just invisible to me, at least until I finally get bitten by one and start picking up on all the other cases of it.

Keywords: blind spots, self-deception

Also, I’d like to contrast the article:

Trying to retrofit a substantial codebase to be clean at maximum levels in PC-Lint is probably futile. I did some “green field” programming where I slavishly made every picky lint comment go away, but it is more of an adjustment than most experienced C/C++ programmers are going to want to make.

With this comment:


The bugs that static analysis tools tend to turn up are ones that Haskell catches out of the gate in general.

Now, there are two ways that Haskell can be more practical than PC-Lint is: first, by being better, and second, by simply flagging fewer errors (trading false negatives for false positives).

I think it’s most likely that Haskell is better than PC-Lint, but the question is, by how much?

This relates to another idea I was cooking up:

Each of these systems is pushed right up to its breaking point. For example, in C we have compilers trying to abuse undefined behavior to make more aggressive optimizations, and the addition of a whole new keyword (restrict) to try to help the compiler deal with pointer aliasing. (Picking on C because it’s my favorite of the four listed, although I’m gradually gaining an appreciation for C++. The other two can pound sand.)

What Every C Programmer Should Know About Undefined Behavior #1/3

Keywords: nothing scales

Also from my other notes:

optimization is a balancing act
when there is a lot of pressure on it, there will always be some transgressions

My favorite example for this one is capitalism.

Regarding the need for CYA when starting a new project in C[#]: I realized that writing an application in C probably isn’t that much additional risk if you’re already using an operating system and cryptographic library written in unsafe languages. Yes, those are better tested, but they’re also much larger targets and can probably cause more harm in the event of an exploit.

Keywords: security