Code: The good and the ugly

Careful C craftsmanship creates correct code. Saying it five times fast is easier than doing it.

Careful C craftsmanship creates correct code.

I'm just back from three weeks overseas. Despite daily trying to keep up with email, some just has to be done from the office; other items are less important and not worth dealing with from the road. So my e-mail inbox is stuffed to explosively-dangerous levels, the desk piled high with papers needed attention, and the voicemail is, well, happily minimal. E-comm has, for me at least, almost entirely replaced the phone over the last decade or so.

A couple of coding themes have popped up, though, from reading clients' code and e-mail from various correspondents.

First is an increasing trend I'm seeing where developers rely on an exquisite knowledge of precedence rules in C, usually inside of if statements. A generic example:

if( variable1 operator1 variable2 operator2 variable3)do_something;

Absent parenthesis to group elements of this expression, the result may be very surprising.

That is bad, but to be fair, it was hard to write good code in Applesoft: there was not enough RAM to put in many comments; variables were limited to two letters; there were no labels, just line numbers; there was no stack for GOSUBs; and we all used lots of GOTOs.
The worst was when you needed to insert a line but you'd run out of line numbers, so you had to GOTO to new code at the end and then GOTO back.

Most developers prepared for interview with sophisticated algorithm such as linked list and binary search tree. They then ill prepared to write simple code such as macro. It is a surprise to me that any developer has difficult time writing simple condition, for loop and while loop although it isn't unheard of. Over the years, I have interviewed and hired developers ill prepared for simple code and fluency in algorithm and developers performed poorly in algorithm but excellent in simple code. Who comes out to perform better in the job? The one who is more cautious of any changes.

I agree, good code is essential, but too often people forget that coding, is just a small part of the software development process.
If you understand your requirements, design your code solution and properly test the software, then you can more easily avoid the simple coding mistakes that cause the problems.
Knowing how to code does NOT make you a software engineer. It just means you know a small part of the process.
Just my opinion.