Cedric discusses the inverted if statement that some languages that Perl and Ruby use. I personally like this feature a lot. You can argue that you don’t “need” it, but it brings a lot of readability to your code.
E.g.
open $THEDOOR if $it_is_closed;
compared to:
if ($it_is_closed) open $THEDOOR
I like the fact that we first read what we want to do, and then we move on to the condition.
I also like “unless”:
do something unless cond;
is a lot more readable than:
do something if !cond;
However, I do understand that you can get on a slippery slope adding keywords for things like this.
yes!
These are indeed great features. I have long loved them in Perl. We have postfix loops in Perl as well. For example:
print foreach @array;
print while ();
I have heard it argued that postfix conditionals and loops are "just sugar" and add nothing of value to the language... if that were a valid argument, we'd all end up using a language like lisp with no syntax to speak of. Used properly, these constructs make the language easier to read and write. Good stuff. :)
Ease of understanding
I must disagree. The current ordering makes more sense:
- the condition is computed first, in the order of execution,
- the order of reading is top to bottom,
- they should match as much as possible.
Even if you use it only in single line constructions, there is a greater risk that you forget to notice the condition (think of a long line).
Cheers
Dumky
Idioms
These constructs actually help the idiomatic nature of Perl.
While it is true that to the computer, the two constructs are the same. To the person who reads the code later, the intent is different. In the first case, the action is more important; in the second the condition is more important.
In answer to the responder who points out that they can be misused, I agree. However, I think that if you removed every feature from a language that can be misused or used to generate hard to read code, you would end up with a language with no syntax and no semantics.;^)
Good note.
Non-English is sometimes good, too
Another good one from Perl and the shells: the elsif statement. It's not exactly English, but it's unambiguous, useful, and self-evident. If Java is going to get foreach loops, I would think they'd consider this, too.
Ease of understanding
Think about when you're speaking English. Think about saying:
"Close the door if you leave the house, or if you are going to be somewhere in the house where you can't watch for stray cats."
compared to:
"If you leave the house, or if you are going to be somewhere in the house where you can't watch for stray cats, close the door."
I would argue the first one is easier to understand (of course... this is a badly contrived example... for that I apologize).
Basically, we like the simple part in the front. It's the same way with these postfix conditionals. They give a programmer the flexibility to put the complex part (if it happens to be the conditional) at the end. Most of the time the "normal" way is used... but occasionally putting the condition after the action just works better.
That's it? :-)
That's the entire article?
Non-English is sometimes good, too
I know very little Perl, so forgive me from asking, but what's the difference between Perl's 'elsif' and Java's 'else if' (aside from an 'e' and a space)?
Standard syntax is also nice
Personally, I like the standard syntax that is used in C, Java, and many other languages. When moving between languages, it is nice to be able to have some things that stay (essentially) the same.
If TEST
DO PLAN A
else
DO PLAN B
If I don't perform a test, I cannnot make a decision. Therefore, why would I wish to "place the cart before the horse" by deciding my action before I make my test?
Variations are wonderful things - until you spend hours discovering that what you THOUGHT you told the system to do is not what you ACTUALLY told it to do! When creating a program design, we must ALWAYS lay out what tests must be made - and in what sequence - so that our program causes the actions that are required in the sequence required.
I would argue that good program design requires us to consider the test that must be performed prior to allowing or initiating any action. From this, it is more nearly logical to place the test before the action, as that more nearly mirrors our design document and psuedo code.
When we start thinking backwards, there is a good chance that we are creating code before we have created the full design of the program. That process is the foundation of much "sphagetti code" that wastes huge amounts of time to revise and debug.
Properly designed and commented code is a wonderful thing. Code that is written without a clear design is a frightful thing. It is a monster that just keeps on sucking the life from the product - and from those attempting to maintain it!