When You Say Nothing At All…

This is another one of those posts that has a bit of a double meaning in the same title. First, there is the matter of a useful hint/warning that I think could be emitted by a Pascal compiler. The other is what I have been up to in recent months that I have been so busy that I wasn’t posting much (i.e. at all) !

First the more relevant point to this blog:

When you say nothing at all, in Pascal

Consider this very simple piece of code:

if SomeCondition then
i := 42
else
i := -1;

Nothing controversial here, obviously (and just as obviously, this isn’t real code; it’s just for illustration). Where SomeCondition is TRUE, i takes the value 42, otherwise it takes the value -1. Simple. What could possibly go wrong ?

The addition of just one character to this code will silently change the outcome completely, resulting in ialways taking the value -1:

if SomeCondition then
i := 42
else;
i := -1;

Do you see it ?

Of course, it’s going to be much easier to spot in an isolated example like this, but imagine reading this amongst the background noise of real world application code and you should appreciate how much harder it could be to identify in practice.

The problem is of course that little semi-colon that has crept in after the else, completing the if-else with a null statement. What I call a “NO-OP” (NO OPeration).

The if-else now has an empty else clause and is immediately followed by an unconditional assignment of -1 to i. Now in this case you do get a hint that the value (42) assigned to i is never used, but I think a more specific warning about the empty statement would be more useful.

Of course, such empty/null statement NO-OP‘s can be useful. I use them quite often with case statements for example, or anywhere else that I need to demonstrate and self-document that some potential case has been “left intentionally blank” rather than having simply forgotten to deal with the case, but I always document them as such:

Or an introduced virtual method which is specifically not abstract but which explicitly has no base class implementation. Or in an override which deliberately suppresses the inherited implementation (i.e. does not call inherited and provides no replacement implementation):

procedure TFoo.OverrideMe;
begin
// NO-OP
end;

You don’t actually need to comment/document your NO-OP’s in this way because they are perfectly valid, but I consider it a useful indication that the NO-OP is a deliberate and considered aspect of the implementation, rather than an accident of oversight or omission.

Which is great when you deliberately introduce these NO-OP’s, but when you do so unintentionally, you get no warning. I think it might be useful to have such a warning, or at least a hint. Of course, this will result in a slew of warnings in existing code which contains perfectly valid, empty statements, and no easy way to deal with those warnings.

Two ways of dealing with this might be:

Introduce a new keyword specifically to indicate a deliberate empty statement. Even without compiler support this could be approximated by simply have a particular named procedure that you call in such cases. This might be preferable anyway given that this would be necessary in code that has to support older compilers which would be unaware of the keyword.

Emit the hint/warning as part of the source parser and allow a comment to be treated as representing a “statement” in such cases. Then as long as an empty statement at least contains some comment (i.e. documentation) it would be considered not requiring a warning.

In the latter case of course the parser has no way of knowing whether any comment in an otherwise empty statement is actually useful documentation for that empty statement or not. So perhaps there should be different levels of strictness that may be applied. i.e. emit hints/warnings for all empty statements or only for only those that do not contain comment(s), to be applied as suits your individual coding standards in such areas.

In any event, any such hint/warning is probably best introduced as disabled/turned off by default.

It’s not a world changing improvement to the language, but it could be a useful one. 🙂

A Busy Start to the year…

As for my own relative silence in recent months… what can I say ? It’s been a very busy start to the year !

In January my fiancée and I resumed house hunting as we had always intended to do after Christmas, expecting it to take a few months. Within a week we had found a house and one thing followed another and another week later we had a purchase agreement in place !

Then in February we got married. Unlike the house, this had been planned well in advance but still took a great deal of last minute organising, not least due to the logistical challenges arising from our decision to get married in Hokianga, a beautiful location in the Far North of New Zealand but about 4 hours drive from Auckland where we live. Natural beauty aside, Hokianga is a special place for us as it is where we went on our first trip away together.

Hokianga in Maori means “Returning Place”.

Then, the week before the wedding we were invited to a ceremony (along with almost 500 other new citizens!) to receive our certificates of New Zealand Citizenship, to occur just a week after the wedding itself.

My wife’s parents had travelled to New Zealand for the wedding and were staying on for a further month after. Being able to be present at the Citizenship ceremony was an unexpected bonus for them. Also unexpected but unfortunate were the events unfolding for them back home, in Ukraine. If you have been at all aware of events in that region you can appreciate that the joy of the wedding was soon overtaken by concern for what they might have to return home to (last week). They live in Donetsk.

Fortunately it has been a relief for them to find that life in Donetsk is actually far less affected by the goings on there than we had feared might be the case in the former President’s home region. We can only hope that things remain that way and that the situation is soon resolved.

One additional complication arising from the wedding came from our decision to blend our names. Had either of us taken the other’s name this could have been achieved simply by making that change on the marriage certificate. But since we were both taking a new name we instead had to apply for a legal name change, separately.

That took effect last week, so I am now legally “Jolyon Direnko-Smith“.

And last but not least (as if all that wasn’t enough to be dealing with!) I decided to move on from my job at Flow Software. I am currently “between jobs”, waiting to take up a new post at Datacom, next week.

So, all in all, very exciting and very busy times. 🙂

And that’s without even mentioning the release of AppMethod and RemObjects Elements with a major new release of Oxygene and an exciting new direction for C# !

A couple of commenters have mentioned these developments already and I of course expect to be blogging about these in the near future, now that the world is spinning at a (slightly) more manageable rate ! 🙂

20 thoughts on “When You Say Nothing At All…”

A comment about your topic: Yes, I agree there should be a warning about else clauses without a statement. In fact, I would argue that it should even be an error–why would there be an else if there’s no statement to execute?

On the other hand, with good software practices in place, unit tests would quickly reveal the flaw!

The error was indeed spotted very quickly. 🙂 And yes, the “else” scenario is the most obvious example of an accidental omission, but there are plenty of other examples where an accidentally empty statement would not be so obviously wrong (and may actually be intentional).

I’d been worried about you and the same night I said to someone that I had to e-mail you to see if you were ok I saw your new post! Glad to hear the things going on in your life are positive.

To address your syntax issues, you need simply turn to the best version of Pascal ever created: Python. 🙂

The issue with the “if” statement is due to the fact that in Pascal and several other languages the indentation can lie to you (and has been the source of some million-dollar horror stories). Implement significant whitespace and the problem goes away.

If some_condition:
i = 42
else:
i = -1

There’s no way I can rewrite that statement that will make i accidentally always be assigned -1. It’s always clear what code is in a control block and mistakes are easily spotted. This is what Pascal needs; I know Eric Grange was considering it for DWScript. Your example here is a very good demonstration of why significant whitespace is so useful.

As for your second issue, Python introduced a statement called “pass” that does nothing. You actually can’t have a completely empty function or class, so

def OverrideMe:
pass

would be the only way to write a function that did nothing.

I’m sure your best friend David I. has you on speed-dial so feel free to call him up and make these syntax suggestions. 😉

w.r.t code formatting, I use the Syntax Highlighter plugin for WordPress with a few tweaks for specific language support (primarily Delphi and Oxygene). For Delphi, enclose code snippets in a “delphi” tag, but using square braces notangle braces:

Yes, I emigrated to New Zealand from the UK, way back in 2005. Fortunately I don’t have to give up my British citizenship as both the UK and NZ allow dual citizenship. I am still a citizen of the UK as well as NZ.

(The oddest part of the NZ citizenship ceremony was swearing an Oath of Allegiance to HM Queen Elizabeth II – seemed a bit redundant since I was already one of her subjects and citizens and thought I was pretty allied already ! 🙂 )

Congratulations on you marriage, new home and new job, I’ve done pretty much the same thing last year. Purchased a lifestyle (life-sentence?) block in April, changed jobs about the same time and got married on our farm in November. I’ll probably have some extra time this year, so look out for new videos.