Jump to content

Is it bad form?


LaRetta

This topic is 3314 days old. Please don't post here. Open a new topic instead.

Recommended Posts

When scripting and I need to run an If/ElseIf piece, I confess that I have gotten into the habit of beginning with an empty If[].  The reason is that it never fails, every time I do NOT begin with an empty If[], I have other ElseIf[] steps and I need to switch the order of them or at least that is how it seems.   :idot:

 

It bugs me that I can't just grab the corner of the ElseIf[] and slide it up and have it change into an If[]. Sometimes it's the little things...

 

I know of a few other closet empty-IFfers out there but I was wondering what others think of the practice ... around the water cooler, ya know?  

Link to comment
Share on other sites

And there are times, wow the confessions are flowing now, aren't they?  Sometimes I am tempted to drop the Else[] for same kind of reasoning. ;-)

 

If they are bad habits, please explain so I can drop them.

Link to comment
Share on other sites

Good morning!  

 

No, empty Else If[]  wouldn't work.  I meant that I was considering ending with an Else If [ true ].  I have not done this yet but it seems the ending Else[] can cause the same grief when I need to move things around (which happens more than I like).

 

It is liken to a sentence ... it begins with a capital and ends with a period but wanting to add more into the sentence logically can sometimes mean uncapping the beginning word or changing the period to a comma (or removing it).  By removing the capital ( the 'if') and possibly by removing the ending (the 'else'), I might never have to fuss with them if the order switches.

 

It isn't that I am lazy (although I am) but more that the existing restrictions on If/Else seem too rigid and inefficient.


And again, for anyone reading, I am just speculating at the moment ... not saying this is good practice.

Link to comment
Share on other sites

I see exactly what you are doing. I can't say I have often been in a situation where I needed to change the order of If/Else If tests. If I was, it's usually only for my own clarity of thought.

 

With that said, if I was involved in a project where the order of tests mattered and could change, I would likely do the same thing. A script that always evaluates False at the If step doesn't really break anything. I wouldn't leave it blank. I would enter "False // Explanation of what I'm doing". Just so it's clear to me later or others that work on the file after me.

Link to comment
Share on other sites

I can relate, and I've done that on occasion, usually with If[0] rather than empty.

 

FWIW, if I came across another developer's script and it was set up like that, I'd have no problem understanding it and it wouldn't bother me a bit.

Link to comment
Share on other sites

No, empty Else If[]  wouldn't work.  I meant that I was considering ending with an Else If [ true ]. 

 

But then you cannot drag this to a higher position, because it would cancel all the Else Ifs that come after it.

 

Anyway, my opinion re good practice is that this would be fine while you (or you and your collaborator/s) are exploring the options - but once that is done I would remove the scaffolding.

Link to comment
Share on other sites

I like your idea of adding a reason "False // Explanation of what I'm doing", David, thank you so much.  A comment is a simple cost-free thing!  And Tom, I also would understand an empty If[].  I appreciate your feedback!

 

But then you cannot drag this to a higher position, because it would cancel all the Else Ifs that come after it.

 

From how I envisioned it, and granted that I have not done this yet (only been tempted), it would never have to leave from being the last entry.  It would be same as an Else[] except it would have no action.  And if last, the Else[] wouldn't ever be needed except ... what would be the difference between listing an Else If[ true] last (never needing to move it) and an empty Else[] always at the end?  I guess this wouldn't be helpful after all.   :ermm:

 

Anyway, my opinion re good practice is that this would be fine while you (or you and your collaborator/s) are exploring the options - but once that is done I would remove the scaffolding.

 

I completely agree ... I do not like leaving unnecessary clutter anywhere, even leaving unnecessary script variables which were used in testing bothers me.  But I would tend to want to leave this scaffolding ( at least the If[] portion ) only because to remove it would defeat the purpose of it later because I would still then need to copy the calculation from the first Else If[] and copy it into the If[] then delete the Else If[].

 

I feel better having confessed.  If I come across a situation where the Else If [ true ] is really helpful (over ending with an empty Else[]), I'll bring it up again; this was an afterthought on my part.  Thank you everyone for speaking up about it.  The day is brighter with a clearer conscience.  :laugh2:

 

edited: changed 'scaffolding' to 'unnecessary clutter' just to remove redundancy in phrasing.

Edited by LaRetta
Link to comment
Share on other sites

  • 3 weeks later...

I was going to 'remove the scaffolding' in this example but upon reading it again, I still believe the If[] should be left because we can't remove it by itself ... it can't start with Else If[] ... I wish it could.  So in this case, the scaffolding will stay. 

Link to comment
Share on other sites

I was going to 'remove the scaffolding' in this example but upon reading it again, I still believe the If[] should be left because we can't remove it by itself ... it can't start with Else If[] ... I wish it could.  So in this case, the scaffolding will stay. 

 

But If[] itself is not a part of the scaffolding; the first Else If[] is. IOW, if you ended up your tests with:

If [ 0 ]
Else If [ test A ]
  # do A
Else If [ test B ]
  # do B
Else
  # do Z
End If

then "removing the scaffolding" would mean:

If [ test A ]
  # do A
Else If [ test B ]
  # do B
Else
  # do Z
End If
Link to comment
Share on other sites

But that is the problem (as I see it and admittedly, I do not always see clearly):

 

To 'remove the scaffolding', I must copy the calculation of test A out of the first Else I[], delete it, then go modify the If[], pasting the test A calculation back in.  Also there are times where I want the FIRST test to be a lower Else If[] ... we simply can't switch them.

 

And this is what bothers me.  Am I just being lazy?  

 

Well I just answered my own question - the answer is yes I was being lazy and I will clean up when done.  It is okay to use stand-alone If[] while creating but once done, clean up my work.

Link to comment
Share on other sites

To 'remove the scaffolding', I must copy the calculation of test A out of the first Else I[], delete it, then go modify the If[], pasting the test A calculation back in.  

 

 

You could tell yourself you are eliminating the possibility of an error by leaving it as it is... ;)

 

 

Also there are times where I want the FIRST test to be a lower Else If[] ... we simply can't switch them.

 

Not quite with you there.

Link to comment
Share on other sites

I can tell myself many things but that doesn't mean it is true or right.  :-)

 

As for the 'lower Else If[]' ... it is same issue ... switching the order of the Else If[] can mean changing the If[].  I like the self-lie that leaving the If[] will decrease possibility of transfer error.  LOL.  I'm unsure I will buy my lie, however.  Thank you!


There IS possibility of transfer error - very very slight, but possible.  Still not enough to claim I am leaving it to be safe from that possibility.  If I leave the empty If[], it will need to be because I admit to being lazy.  Not sure I can do that.

Link to comment
Share on other sites

If this is a process that over time can change ( order of tests being a factor in the outcome ), I see zero reason to remove the scaffolding. It's simply more work at that point.

 

If we were talking a text-edit based scripting, yeah, maybe its just lazy. But we aren't. This is an option buried inside a dialog. Removing the need to move text from one container to the other is efficient and smart.

 

It would be like trying to move the water in barrell B to barrell C and barrell C to barrell B. Which means you have to pour the water into a temp container, same with the other barrell, and pour it back into the opposite barrell. You are going to lose some water...and maybe a lot of it. ;)  Instead, you move barrell C into the spot where barrell B was, and barrell B in the spot where barrell C was. It's safer, easier....and if you really need to, you can also swap the labels.  :grad:

Link to comment
Share on other sites

LOL, Josh, well if we could just switch the labels - that is what I want - switch an End If[] for an If[] then switch the If[] for an End If[]!!  When we have 'like' items, we should be able to switch the labels!

 

I will put the request in to FileMaker.   :laugh2:

Link to comment
Share on other sites

It would be like trying to move the water in barrell B to barrell C and barrell C to barrell B.

 

No, it would be like trying to move the water in barrel B to the (empty) barrel A and discard barrel B.

 

 

And we're not talking about moving water, so the analogy doesn't really hold - esp. the part about losing some water.

Link to comment
Share on other sites

No, it would be like trying to move the water in barrel B to the (empty) barrel A and discard barrel B.

 

 

And we're not talking about moving water, so the analogy doesn't really hold - esp. the part about losing some water.

 

Not if you are talking about moving the parts inside the If/End If. Barrel A will always be empty. It's just a place holder.

 

Copying and pasting a calculation from an Else If, to and If opens up room for error.  That's what the reference to losing water was about.

Link to comment
Share on other sites

Not if you are talking about moving the parts inside the If/End If.

 

 I believe that since the reopening of this thread  in post #10, we're talking about moving the very first test from the (fake) first Else If[] to the If[] step itself. Where it should have been in the first place, but some people wanted to experiment first...

 

 

Copying and pasting a calculation from an Else If, to and If opens up room for error.

 

Yeah, well - that's what I suggested in post #13. But I was (at least) half-joking. I mean, if that's a consideration, then you'll never clean up anything that happens to work, no matter how convoluted it may be.

 

I sense there's a larger issue lurking here. It has to do with how much control do you have (or think you have) over your code. Everyone can make a mistake, but if one is reluctant to polish up their code for fear of spoiling it, then it's not really their code, is it?

Link to comment
Share on other sites

Overall, I would say 1 out 500 of my If/Else If statements are dependent on the order. So it's rare that I see the need to employ this strategy. But it is far easier to shift a group of steps to another slot in the test progression if all of the tests are held in the Else Ifs. But this all only matters IF the series of tests are dependent on the progression order. Having a guaranteed false result as a place holder in this rare instance...I still don't see as a violation of good practice.

 

If they are not dependent on the progression order, then I completely agree, there is no use case I can see for not making the first test happen in the If step.

 

99.8% of my If scripts are going to go:

If [ Test A ]
  # Do action A
Else If [ Test B ]
  # Do action B
Else
  # Do action Z
End If

But there are a lot of scenarios where one has to test each sub-set of data independently, and receive a FALSE result, before moving to the next progression of tests. For that, I almost always include the "If [ 0 ]" step, so that I can at any time shift the succeeding tests around as laws, business logic/rules, change. I just simply don't run into those too often.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.