Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto Professional Forum - View Post
Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Original thread:
Post 4 made on Sunday March 22, 2009 at 06:42
Rusty Fobe
Long Time Member
Joined:
Posts:
December 2008
47
It could be wise to put a selection tree in a separate function, not only just to make your code more readable, but to make use of the nice feature of the explicit return statement, with which you escape from the selection tree whenever you want ! Furthermore, it offers the great possibility to pass values to the calling function. In that separate function you can of course use switch and try too, next to or in place of nested if's.

function xyz() { // the calling function
var result;
statements setting arguments
result=selectionTree (arguments you need to decide upon);
switch (result)
case "expr 2 true":
et cetera

function selectionTree (arguments you need to decide upon) {
if (expr 1) {
do this and that
if (expr 2) {
do these things also
return "expr 2 true"}
else {
do other things
return "expr 2 false"}
if (expr 3) {
return "expr 3 true"}}}

Just a note on goto.
I don't want to be patronizing, and with all due respect to Lyndel, who merely just said it is possible, but probably never uses goto's himself ;-), that would surprise me.

Avoid goto's completely, even if they are provided by a language (unless that language does not offer other solutions of course, but that is very unlikely as far as I know). Goto's are an old technique coming forth from procedural languages. There has been a huge struggle in the 70ties and 80ties to learn people how to avoid them with a technique called gotoless programming. Goto's often lead to pretty unreadable code and mistakes. Goto's (or better the misuse of) were one of the triggers that lead to better features in languages. Goto and their labels also disrupt your otherwise nicely built functional structure.


Hosting Services by ipHouse