Odd script behaviour (aka Beware of Inline Coding)

[MadDogDean]

Hello all,

Running through the Notes Building App course. Just had a row of pulling out a good portion of my hair. "Why, oh why doesn't it work??! Arghhh!!!!"

I discovered (is it by design or bug??) that this will compile fine, but doesn't work as intended. Although the internal "end if" is missing the Script editor has no problem with it.

Code: Select all

   if tNoteID is empty then
      put getUUID() into tNoteID
   else

      -- inline statement below
      if deleteNote(tNoteID, tNotesFile) = 0 then answer "Error saving note." 
      -- with no "end if" it will compile fine

      exit mouseUp      
     
   end if

But, split the line on two lines and it fails to compile (as expected)

Code: Select all

   if tNoteID is empty then
      put getUUID() into tNoteID
   else

      -- inline statement broken
      if deleteNote(tNoteID, tNotesFile) = 0 then
      answer "Error saving note." 
      -- will not compile with missing "end if"

      exit mouseUp      
     
   end if

Not earth-shattering, but hopefully it'll help someone else.

Cheers,
MadDogDean

[dunbarx]

Hi.

The first handler is properly formed. Not sure what you are seeing.

You are missing an "end if" in the second handler, at the end.

Note, in general, the many ways to construct if-then clauses are not quite perfect, at least as far as automatic indentation goes. This goes back nearly 30 years, to HC days.

If in doubt, do it long-hand, especially not compressing interior if-then clauses. Though it takes more space, the compiler is always happier, and readability is usually greater.

Craig Newman

[MadDogDean]

Hi Craig,

What I was getting at is that the seemingly identical code (except for one CR) is handled differently by the compiler. I hadn't really expected the compiler to differentiate between a CR in sample 1 or 2.

In LiveCode, is there a difference between an if...then on a single line vs. if...then on two lines?

Using the in-line style wasn't intentional, just a slip of the keyboard, but quickly it can cause a problem with no indication of an error.

Cheers,
MadDogDean

[Dixie]

The first 'if' statement is looking for 'end if'... You could have constructed your handler :-

Code: Select all

   if tNoteID is empty then
      put getUUID() into tNoteID
   end if
   
   if deleteNote(tNoteID, tNotesFile) = 0 then
      answer "Error saving note." 
      exit mouseUp      
   end if

or to use 'else if'...

Code: Select all

on mouseUp
   if tNoteID is empty then
      put getUUID() into tNoteID
   else if deleteNote(tNoteID, tNotesFile) = 0 then
      answer "Error saving note." 
      exit mouseUp      
   end if
end mouseUp``

See the difference >

[MadDogDean]

Hi Dixie,

Thanks for your input as well. I guess I wasn't clear on what I was getting at. It was more of an observation than solving an actual problem.

Where my confusion came in was with the compiling of the inline if...then statement.

For example, this works and compiles:

Code: Select all

on mouseUp
   if 0 = 0 then answer "Good job"
end mouseUp

This doesn't compile (and the only difference is the CR after the "then") and we get a "button "Button": compilation error at line 4 (if: missing 'end if'), char 1" error message

Code: Select all

on mouseUp
   if 0 = 0 then 
   answer "Good job"
end mouseUp

Cheers,
Dean

[Klaus]

Hi Dean,

that's the way the enigne works!

If you have "if...then..." in ONE line, it will compile!
If you add a CR after "then" then an "end if" is mandatory.

I ALWAYS use END IF, even if I could use a one-liner, since this is better readable at one glance!
And I NEVER could get accustomed to any "elseif" clauses.


Best

Klaus

[Martin Koob]

Another odd thing about 'if ... then..' in one line is when you are in debug mode.

As you are stepping through the code it takes two steps to get past the one line 'if..then..' so the debugger is treating it as two lines.

Martin

[SparkOut]

Hi Dean,

that's the way the enigne works!

If you have "if...then..." in ONE line, it will compile!
If you add a CR after "then" then an "end if" is mandatory.

I ALWAYS use END IF, even if I could use a one-liner, since this is better readable at one glance!
And I NEVER could get accustomed to any "elseif" clauses.


Best

Klaus

me too, exactly. Even though I understand those constructions, I don't feel comfortable with the idea of writing code like that.

[MadDogDean]

Hey, I'm with you all. Spell it out and it makes a lot more sense (especially when you come back to it in 6 months to make a change!)

Here's one I remember coming across when I was doing some PHP work a short while ago. It was to determine thenumber of days in a given month.

Follow it through and it makes sense, but do this with some sort of data you're not familiar with and it'll flash one of those "Huh??!?" moments

Code: Select all

$days = ($month == 2 ? ($year % 4 ? 28 : ($year % 100 ? 29 : ($year %400 ? 28 : 29))) : (($month - 1) % 7 % 2 ? 30 : 31)); //returns days in the given month

Cheers,
MadDogDean

[jacque]

I ALWAYS use END IF, even if I could use a one-liner, since this is better readable at one glance!
And I NEVER could get accustomed to any "elseif" clauses.

I had a near-disagreement with Jerry Daniels about this one time. He's with you, Klaus, he always puts if/end if statements around every conditional. I'm a one-liner whenever possible. I've been doing that since HC and it's second nature to me. I don't have any trouble understanding it, and it makes the code more compact. If the statement is long, I sometimes use 2 lines. Otherwise, I block it out with if/end if.

In case anyone in this thread doesn't know, this form is also okay:

if whatever
then something -- 2 lines

Else-ifs aren't much different than case statements in a switch block, only more verbose. If there are only two or three things, I use if/else if. If there's more, I use switch, usually.

So we have three ways to write "if" statements:

Code: Select all

One line:
   if whatever then something

Two lines: 
  if whatever
  then something

Three or more lines:
  if whatever then
    something
  end if

if whatever then
  something
else if someOtherThing
  somethingElse
else
  lastThing
end if

Personal style. Probably no one else could work with my scripts. The main thing is that each of us understands it ourselves.

[Lagi Pittas]

HI All,

I'll go into "Craig" or "Simon" Mode

put the following in a button script and <press>

on mouseUp

Code: Select all

   if true then add  10  to tvar ;  answer( "tvar = TEN : " && tVar ) ;   add 5 to tVar;  put " tvar = fifteen" && tvar
   
end mouseUp

This isn't a mistake - it was specifically programmed that way.

The Parser uses <return> or CR or space as a statement separator and terminator as opposed to "C" that uses semicolon as a statement separator (from memory ) so if you have multiple statements on 1 line in C you need to separate them with a semicolon. JavaScript has its ASI (Automatic Semicolon Insertion) and does just that - But Hypertalk was there first.

Try the following code

Code: Select all

on mouseUp

   if true then add  10  to tvar   answer( "tvar = TEN : " && tVar )    add 5 to tVar put " tvar = fifteen" && tvar  if 1=1 then answer "false" 
   
end mouseUp

It works as expected although adding a final else clause discombobulates the Parser and executes the final else instead of the true ( 1=1)

The reason splitting the line fails is that the then is the start of a statement (compound statement) terminated by the end if. But you have premature termination (pun intended!) with the end of line.

It's a matter of style and mostly I use the long form but rules are made to be broken ....

for example

Code: Select all

   if a = 1 then dothis
   if a = 2 then dothat
   if a = 3 then dotheother

Sometimes its clearer than any switch/case statement and shorter and who cares about a few extra tests the compiler has to execute and the extra few bytes of code.


Lagi

[dunbarx]

I will go into Lagi mode.

He is utterly correct. Readability, which always (eventually) translates into manageability, is more important than compactness, or wordiness for that matter. The matter of style is personal, and as good as the person.

Klaus likes open multi-liners. One advantage there is that one can add or delete lines of code directly into the local clause of interest. This is really, really compelling.

I like one-liners like Jacque does, whenever I can get away with them. But she and I go way, way back.

Craig

[jacque]

The Parser uses <return> or CR or space as a statement separator and terminator as opposed to "C" that uses semicolon as a statement separator (from memory ) so if you have multiple statements on 1 line in C you need to separate them with a semicolon. JavaScript has its ASI (Automatic Semicolon Insertion) and does just that - But Hypertalk was there first.

LC also accepts semicolons as a statement delimiter. If you use semicolons you don't need the leading spaces.

Edit:

if a = 1 then dothis
if a = 2 then dothat
if a = 3 then dotheother

This requires the parser to examine every line. Using "else if" avoids that and is faster since it acts much as a switch statement and will exit the block as soon as the first match is found.

[Lagi Pittas]

Hi Jacque,

In fact I had a longer response that listed the code with the semicolons as well but even with semicolons the else does not work on a single line, and although I could remember that in BASIC (BBC BASIC i'm 100% sure but not VB or others) the" if then else" conditional can be on 1 line.

As I say, I stick with the verbose version but i'm not dogmatic about it. I did most of my business programming on the Apple ][ using UCSD Pascal and always found Pascal to be one of the most readable languages especially after COBOL, FORTRAN and BASIC prior to Pascal.

I've now got past the PUT A into B syntax of LC and the lack of dot notation to be very comfortable with it now - that's what stopped me giving LC a real go for about 6 or 7 years after Microsoft stopped developing FoxPro in 2004. Although I still write programs in it when needed -

If all you have is a Hammer everything looks like a nail

- I still use Delphi and Python or whatever when a library is available that does what I need - horses for courses.

Anyway "It isn't Odd behaviour", it's flexibility and it's upto the programmer to decide what to use, how and when.

Rules are meant to be broken - especially your own

Lagi