And now for something totally different... At the weekend, I spent some time chatting to a (software) development manager for a sizeable public company. He spends a lot of his time trying to persuade his coders to stop using C/C++ contractions. Without prompting (he's nothing to do with the OU!) his reasons are:

1. They do nothing for optimisation in these days of good optimising compilers.

2. The can severely reduce readability and maintainability; this last is his chief concern as well over 50% of their work is maintaining old code (and some of the other 50% is working out how to hook in enhancements requested by users).

3. With some libraries, they can severely damage the code semantics.

The moral is: don't use ++ (pre or post), +=, -=, or any of the other <something>= contractions. Don't use "zero means false, non-zero means true"; if something is a boolean, use bool; don't use statements in conditional statements; don't use the fact (C/C++ peculiarity) that assignment statements have a value; use while when you mean a while loop and for when it really is a for loop;

Code:

while (true)
{
...
if (...) break;
...
}

is a total no-no; etc., etc.

Rant over (for now).

Posted by one of the OU tutors, and reproduced here with his permission.

I'm not experienced enough to comment, but does ++ and += really obfuscate code that much?

06-02-2006

dwks

No, quite the opposite. i += 5 is the way you think. You think "add 5 to i", you don't think i = i + 5, "get i, add 5 to that value, assign the result to i". I think it makes the code easier to read.

06-02-2006

Prelude

>but does ++ and += really obfuscate code that much?
No. People who find it confusing when used properly likely don't know the language as well as they claim. This seems like a blanket ban on features that have the potential for abuse, which is stupid.

06-02-2006

RobR

Should have perhaps mentioned that the OU (Open University) course I'm currently doing insists on i=i+1 instead of i++...

06-02-2006

Thantos

Whenever I write code, regardless of the language, I try to use the operations that make since and aid in reading of the code.

To me ++ and -- mean to go on to the next value/item or return to the previous value/item.
So I use them in that context. Sometimes doing:

Code:

obj = obj + 1;

doesn't really make a lot of sense. For example lets take the often misunderstood pointer arithmatic:

Code:

int x[10] = {0,1,2,3,4,5,6,7,8,9};
int *ptr = x;
ptr = ptr + 1;

Now for those of us that have studied it that bit of code doesn't confuse us. However take a newbie and show them that code and they'll look at you crossed eyed and drooling. I know because I've seen it in those that I've tutored.
Now if you were to show them this:

Code:

int x[10] = {0,1,2,3,4,5,6,7,8,9};
int *ptr = x;
ptr++;

Most would understand that ptr is now pointing at the next element.

Now onto += and the like. The real benefit is not having to type out the name twice and taking the risk of mispelling it. I see nothing wrong with using them as they are very clear in their operation.

As for your while loop example, it might not be the prettist but sometimes it can be the best.
For example say you have a main loop in your program that does the processing as it becomes available. Half way through the middle of the loop you have some type of exit condition (maybe due to an exit code or fault). Now this condition doesn't exist at the beginning of the loop. So where do you place the conditional?

With a few expections for things like gets() pretty much anyone who says not to use a tool needs to be shot. Just because they are too stupid to know how to use the tool properly doesn't mean its a faulty tool.

06-02-2006

Perspective

i += i++ + ++i; wheeeeeeeeeeee!

*no, there isn't really a point to my post. I think += and all that jazz is perfectly readable and should be used in any way except the above.

06-02-2006

Mario F.

++ and --: I don't think he can defend his point of view on this one. Since when obj = obj + 1 is more obvious than ++obj or obj++?? Especially when dealing with pointers and iterators? They are called incrementing operators for a reason. And they are not specific to C++. They are so widely use that what seems strange is not seeing them on any line of code.

Some terse statements in C++ are so widely used that it simply seems strange not seeing them anywhere: *p++;

The alternative involves two lines of code and twice the chance of typos.

+= and it's brothers: This one is a bug killer. How many times do I forget to properly include everything within parenthesis on more complex expressions on the right hand operand. Now... let's add another pair of parenthesis because my boss likes obj = obj + something better :)

0 for false: Some functions simply cannot return a bool. They need to return an arithmetic type and that type needs to be checked for validity. The alternative would be to either set a global variable or add a referenced bool to my argument list. No thank you.

Besides both the standard library and the STL rely heavily on 0 for false and everything else for true. Unless he doesn't use these two libraries anymore he has no choice than to swallow this one :)

I would like to know too how he thinks about checking for NULL. Is this also a no-no? I suppose...

break statements: What do you call a loop without break and continue statements? A boring loop which has no imagination and can only be tested for one condition. In short, a poor loop. I prefer richer loops than can be tested for more than one condition.

06-02-2006

whiteflags

In general, smacking the B&* hammer on a feature of any language is a stupid idea; claiming something cannot be used forever. Take your teacher's advice with a pinch of salt.

B& = banned, for non4channers

06-02-2006

itsme86

WTF is a 4channer?

06-02-2006

itsme86

WTF is a 4channer?

Anyway, agreed. This "developer" sounds like a moron.

06-02-2006

JaWiB

Those sound like some pretty dumb pet peeves to have.

>>use while when you mean a while loop and for when it really is a for loop

I don't see how this could be a big problem. I mean, it wouldn't make much sense to do:

Code:

for(;condition;)
{
}

But it doesn't seem that much less readable than the while loop to me. (And I don't think I've actually ever seen anyone do this.)

I guess I could see a problem between using do...while and while or for, but I'd be surprised if that was a common mistake.

06-02-2006

gcn_zelda

However, I've seen some novices use:

Code:

int condition = 1;
while(condition == 1)
{
:here

// do a tap dance. get user input. if user pushes 1, condition = 1.

if(condition != 1)
{
goto here;
}
}

Or something like that. (I haven't programmed in forever.)

06-03-2006

VirtualAce

So basically take out all the cool things you can do in C/C++ for the sake of readability. It would increase the length of the code, hamper readability, and look more like BASIC than C/C++.

Nothing wrong with:

Code:

if (FAILED(GetDevice())) DoSomething();

06-03-2006

laserlight

Quote:

The can severely reduce readability and maintainability; this last is his chief concern as well over 50% of their work is maintaining old code (and some of the other 50% is working out how to hook in enhancements requested by users).

From what I see, when they are used correctly as expressions of concepts, they can enhance readability and maintainability. Like what Thantos wrote: "To me ++ and -- mean to go on to the next value/item or return to the previous value/item." Likewise, "x += n" would mean something like "advance x by n places". But "x = x + n" means "advance x by n places, assign result to x". It (probably, and should) does the same thing as "x += n", but the meaning is not exactly the same.

Quote:

I would like to know too how he thinks about checking for NULL. Is this also a no-no? I suppose...

Well, it is true that there is no need to check for NULL before doing a delete.... :P