Cortical recently wrote:
#EXIT - good coding always has an exit last step
Exit Script [ ]
I dont understand why does "good coding always has an exit last step"?
What are the potential issues if you dont?
I wonder what the reasoning behind that?
Exit Script  is useful if you need to capture data from the script but in general i don't see the need?
I use it mainly for a place holder when stepping while debugging. Any step but the last can be analyzed. Ergo make exit script that last step.
-- sent from my iPhone4 --
"Good code" needs no debugging. My code is SOOOOOOO good, I have no need for Exit Script as the last step.
*chuckles and goes back to debugging*
Beverly Voth wrote: Any step but the last can be analyzed. Ergo make exit script that last step.
Beverly Voth wrote:
Any step but the last can be analyzed. Ergo make exit script that last step.
If I follow your logic, Exit Script should be the step after the last...
Good coding follows the requirements of the language it is written in and in FileMaker it is unnecessary since it always exits itself when it ends. Eliminating fluff and bloated code is also good coding practice.
--- official response from the Department of Redundancy Department ---
Good coding does not suffer ultimatims (except when it does to satisfy a behavior specification). Including an Exit Script  step at the end of a script is a common best practice for the reason Beverly stated above. I nearly always include an Exit Script  step for this reason in addition to returning a result. If a script has no other result to return, I'll at least return an error code indicating whether or not everything worked according to plan so any parent script (even if the parent script doesn't exist yet or I have no plans for one to exist) can know that the sub-script did what it was supposed to, or what went wrong so the parent script can do something about it.
Eliminating "bloated code" can be good coding practice, but it's a relatively low priority among many competing qualities of code. Higher priorities that often lead to more rather than fewer lines of code include:
If code is longer than a different solution to the same problem because of any of these factors, it is neither "fluff" nor "bloat."
jbante wrote: Including an Exit Script  step at the end of a script is a common best practice for the reason Beverly stated above.
Including an Exit Script  step at the end of a script is a common best practice for the reason Beverly stated above.
What reason is that?
jbante wrote: If code is longer than a different solution to the same problem because of any of these factors, it is neither "fluff" nor "bloat."
A code is "bloat" when it makes no difference.
Michael Horak wrote: jbante wrote: Including an Exit Script  step at the end of a script is a common best practice for the reason Beverly stated above. What reason is that?
Michael Horak wrote:
When stepping through a script in the script debugger, the script (and any script-specific state) currently under developer scruitiny will disappear from the debugger will disappear immediately after the last step is executed. This potentially makes it difficult to analyze the result of the final step for reasons ranging from local script variables no longer being available in the data viewer to disrupting the developer's train of thought. By always having an Exit Script  step in place after any script steps that actually accomplish anything, the debugger will stay open on that script after executing the last behaviorally relevant step, which gives the developer more time to analyze the state.
Remove the scaffolding when the building is finished.
This, BTW, applies also to all those calculations written as =
Let ( [
result = ...
Message was edited by: Michael Horak
Wait...are we ever "finished"? lol
"Remove the scaffolding when the building is finished."
This analogy does not work; for several reasons.
First of all, scaffolding implies something complex and obstructing.
Having a common exit point doesn't obstruct anything.
Secondly, as Jeremy points out, having a last exit step allows you to easily observe an entire script in debugger and stop at the end before completing and exiting.
Even if the script is bulletproof you may still wan to observe it at any time in the operating lifetime of the solution. What values were declared in variables? What data was supplied to the script?
Third, if the script was built to support a single exit point then you may be significantly changing the script structure if you allow spaghetti exits.
It seems highly unlikely that the previously cited designers of unix arrived at their preferred structure merely from dogma.
there is also the effect of exit script(false) which will stop the script trigger from firing if it is a 'before' action.
so at the very least a logic of
if (this worked)
exit script (true)
exit script (false)
Retrieving data ...