C style logic and refactoring

Question

I love languages that evaluate a single expression both as a value and as a boolean value. For example A = 1 evaluates to true, and so does 1. If this practice is very common to the developers in my think tank, is it wrong not to refactor out these expressions, assuming no side effects?

I have a long standing discussion at work talking about code smells, but this logic complexity is why I like C so well. It will be tough for me to switch to Java for example, which does not allow this effect (false != 0).

Any thoughts?

Answer 1

This is totally subjective, but I think that this makes the difference between, say, Perl (which allows you to express something in many different ways, to varying degrees of...clarity), and Java (which is more-or-less quite a bondage-and-discipline language). Some people like (or need) the structure, in which case Java suits them better. Others like the creativity that a freer language allows.

If you have a team of seasoned programmers, then a creative language would allow them to get more work done. And if you have coworkers who like "tighter" languages, well maybe that says something too, or maybe not. But that's just my opinion. :-P

Answer 2

There is no real reason to, en masse, refactor out the use of non-zero values as true and nulls/zeros as false. However! Often these can be a hamper to readability. Often times with pointers, I'll use if (somePtr != NULL) rather than just if (somePtr) because I feel it better describes the intention of... not dereferencing a null pointer.

If the logic is overly complex, it's a matter of readability, but if you don't think it's difficult to read? why the need to refactor?

Answer 3

Java is strictly typed which I happen to think has many advantages; if prevents alot of crossover errors for one thing. I think the flexibility and control of C have their place but so does Java which really shines in making sure that large teams are not dragged down too far by bad programmers. C and Java a similar in syntax but not the same; Java was made like it is for good reason and I'm all for that reason.

Just my opinion though; plus you could break that strict typing in Java with a few clever overloads or new functions.

Answer 4

I think it's really just a matter of how well known the idioms are.

The linux kernel, for example, has a lot of idioms.

For instance, you never do

static int x = 0;

Instead, you do:

static int x;

(the compiler will make it zero. Argue with the kernel guys, not me.)

You don't do:

if (x != NULL)

you do:

if (x)

you don't do:

if (something == whatever) return 0; else return 1;

you do:

return (something != whatever);

And, occasionally this mixing of integers with booleans can come out really handy, like this: build_assert.h

the meat of which is:

#define EXPR_BUILD_ASSERT(cond) \
   (sizeof(char [1 - 2*!(cond)]) - 1)

They use gotos liberally for error handling paths, which is a bit contrarian.

The one or two line things are probably a wash when it comes to readability and maintainability. It's trivial stuff. The real meat in the maintainability and readability departments is (from my experience) in larger scale things. To me, a lot of the OOP stuff tends to make code easier to WRITE, but harder to READ, and harder to DEBUG. To me, that's a net loss. So, I'm not a big fan of oop. Oops... I veered off topic.