OSNews

I actually prefer the first way myself, even though I can read the second. In general, I don't mind code that's a little more verbose, if it's easier to read.

Obviously though, there is a tradeoff between readability and verbosity; if you're using 30 lines of code to do something that could be done in 3, you could probably do better. On the other hand, if those 3 lines of code look like modem line noise on a terminal (as many perl scripts seem to end up looking like), I'd rather have the 30 lines

But again, this is all down to experience. A good Perl developer should be able to read that code easily enough.

Where I draw the line is over-engineered regex:
* they can be completely unreadable - even to many seasoned developers
* and they usually run slower then multiple, more precise, expressions.

A basic example is a 'trim' command. The following will remove spaces from the start and the end of the string:
s/(^\s|\s$)//
However it's actually computationally less efficient then having two separate replaces:
s/^\s//
s/\s$//

So the real issue isn't Perl's syntax, it's that you're either reading bad Perl code, or that you're not familiar enough with Perl to understand it's syntax.

And this is my problem with people who bang on about how bad Perl / C++ / etc is for readability vs Python / VB / etc. Those people are generally inexperienced developers and thus not really qualified to comment. It's a bit like saying simplified Chinese is less readable than English, because I'm an English speaker who's only exposure to Chinese is from friends of that heritage.

If it is purely a readability argument, I see no reason to not use the increment operator, as long as it is alone or just being used in a loop construct. Throwing it into an array index or dropping it into a computation is confusing and dangerous.

Your teacher may have just been trying to avoid having to deal with explaining prefix vs postfix increment, how they evaluate, and all the confusion that usually leads to with a newish programmer. Sometimes teachers do things that seem silly and pointless when your still green around the ears but 20 years later you go "yeah, I get it now"...

Edited 2013-01-16 02:56 UTC

A compiler would just use an inc command in both cases... Though a++ makes sense only with integer variables.

a = a + 1 = a.operator+( T other )
a++ = a.operator++( int )
++a = a.operator++()

Three completely different function calls

Probably because he came from a Pascal background, in many case "readability" means "what I am used to read"..

I have a special thing for "a += 1;" myself: quite short and doesn't have the pre/post issue of "++".

There is a very big difference between "not being able to do something" and "preferring something else."

a = a + 1 has little ambiguity to it, whereas a++ may have a rather ambiguous behavior: i.e. When does the value for a get updated? Is it implementation specific? etc, etc.

Well, if you find that ambiguous, then perhaps you should find another profession. The behavior of the prefix increment is very well defined,and is a very, very basic topic that most books cover within the first 3-5 chapters.