PICED won't compile empty IF / THEN / ELSE

Hi All,


I'm playing with my new PAC and loving it so far, however I've found tonight that the below (edited) code won't compile if I comment-out the (unwanted) "DELAY 1s" line:

if TimerRunning(3) then {this is either a re-entry or fan not yet started}
delay("0:00:01")
else if (GetLightingState("B2 fan timer")) then
begin
TimerStart(4); {start the count-up timer}
end;
TimerStop(3); {kill the count-up timer}
end;



All I'm trying to do here is turn an IF statement on its head, only giving the code something to do if the condition is FALSE (the ELSE statement), however it appears that the compiler doesn't see an "IF" condition with no resulting action as valid, something I'm used to being able to get away with in other languages.

Can I consider this a bug which might be sorted in future releases, or is there a semi-colon I've missed somewhere? (I'm using PICED 3.4.0.0, BTW).

Functionally this code works fine for me in the simulator - all I'm querying is whether I should be able to write an IF statement (as a positive) and then only act if it's false (the "ELSE") as is my desire here. (It's just that sometimes code flows more logically here, rather than testing for the negative "NOT" condition, I want to test for the reverse.)

IF <conditional test>
ELSE
<code does something here because it's not>
END


Also, who do I need to bribe to have the standard windows "control arrows" enabled in the editor: ^right takes me a word to the right, ^left a word to the left, ^A for that matter highlights all text in the module... (I really, really, miss my sideways arrows!)


(But loving my new PAC.)



Greig.

 

I would suggest writing your code as

Code:

if not condition then
begin
  { statements }
end;

In theory the compiler should allow this. I will look into it.

The problem with this is that we are using a third party component for the code editor, and there are some limitations (such as this one) which we can't do much about.

Glad to hear it.

 

the above code is missing a begin statement:

if TimerRunning(3) then {this is either a re-entry or fan not yet started}
delay("0:00:01")
else if (GetLightingState("B2 fan timer")) then
begin
TimerStart(4); {start the count-up timer}
end;
TimerStop(3); {kill the count-up timer}
end;

^---- where is the matching begin to this end? Maybe this has something to do with the inability to comment out the delay?

I would have theought the above code placed in a procedure would fail to compile.

 

Well spotted Anthony. If you try to compile the above code, the compiler does indeed raise an error. Double clicking on this error message brings up a message advising that the most likely cause is a missing "begin".

The compiler DOES accept the following code as being valid :

Code:

if condition then
else
  statement;

but in my opinion, it is not particularly good programming practice.

 

Code:

if TimerRunning(3) then {this is either a re-entry or fan not yet started}
  delay("0:00:01")
else if (GetLightingState("B2 fan timer")) then
begin
  TimerStart(4);      {start the count-up timer}
end;
  TimerStop(3);      {kill the count-up timer}
end;

Since Darren has commented on programming style I thought I might add my opinion on something that bothers me in the above code.

I would like to discuss the lines with comments:

Code:

if TimerRunning(3) then {this is either a re-entry or fan not yet started}
..
TimerStart(4);      {start the count-up timer}
..
TimerStop(3);      {kill the count-up timer}

The first line is fine. The comments describes the intent or purpose of the code, rather than the implementation. Full marks, good commenting.

However, the last 2 comments are dangerous, and I believe in the example misleading.

The first problem is that both comments refer to a "count-up" timer, when clearly the code says that 2 different timers are being referred to (Timer 3 & Timer 4). This poses a serious problem to someone debugging or trying to understand the code.

The second problem is the comments add little value to the code. They are expressing what the code does, in a way that is no more clearer than the code itself. I would consider the procedures TimerStart and TimerStop to be clear enough to make comments "start the timer" and "kill the timer" redundant.

So the only value in the comment is the naming of the timer, which, from the early example, was wrong anyway.

So how to fix the comments? Delete them.

"But shouldn't I include the correct 'name' for the timer at least?"

Yes, but not as comments. Always express in code what you can express in code.

Code:

constants
  REENTRY_TIMER = 3
  FAN_RUN_TIMER = 4

--

if TimerRunning(REENTRY_TIMER) then {this is either a re-entry or fan not yet started}
  delay("0:00:01")
else if (GetLightingState("B2 fan timer")) then
begin
  TimerStart(FAN_RUN_TIMER);
end;
  TimerStop(REENTRY_TIMER);
end;

The above example is as clearer than original comments, whilst always being technically accurate. It is less likely to "rot" over time. By rot I mean the code changes by the comments don't.

There is a lot that can be said about commenting code, but a few rules I always try to follow are:

A) Only comment at the level of intent of the code, not how it is doing it.

B) Write code that is as readable as English so comments about how it works are not necessary.

The are exceptions to the rules of course. Complicated formulas or difficult algorithms need lots of comments. But since this is rare you can always take the time to ensure the comments are accurate.

 

Thanks Guys,


I've tried to reproduce last night's strangeness, however I now concede that I cannot. Last night, add the braces, code won't compile. Remove the braces, "Compiled OK", hence my query re whether my 'reversed' code was meant to compile.

As for my commenting and timer descriptions, had I realised my "Hello World" (first PICED) programming exercise would be held up by the teacher as an example for all, I'd have gone to some more effort to tart it up a bit.

Rest assured any future assignments I hand in will be much more elegant.



Greig.

 

Richo raises the issues of different timers being referrenced in your code example.

When using several timers in a program I have found it very helpful to declare constants for the timer numbers. This makes reading code (for yourself later, and others at any stage) much easier to understand. If you use these products for commercial reasons ie, you are programming for many installations declaring constants like this and good comments are like gold.

{I should take more time to read long posts - Richo has already covered this in the second half of his reply.}