Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38771 > unrolled thread

Drop off an if evaluation?

Back to article view | Back to comp.lang.javascript

Contents

  Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-10 23:45 -0700
    Re: Drop off an if evaluation? Arno Welzel <usenet@arnowelzel.de> - 2020-09-11 09:05 +0200
    Re: Drop off an if evaluation? Julio Di Egidio <julio@diegidio.name> - 2020-09-11 03:33 -0700
      Re: Drop off an if evaluation? Julio Di Egidio <julio@diegidio.name> - 2020-09-11 07:01 -0700
        Re: Drop off an if evaluation? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-09-11 18:20 +0200
      Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 10:05 -0700
        Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 10:19 -0700
        Re: Drop off an if evaluation? Julio Di Egidio <julio@diegidio.name> - 2020-09-11 11:20 -0700
          Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 11:43 -0700
            Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 12:18 -0700
              Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-11 14:28 -0700
            Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-12 20:59 -0700
              Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-12 21:49 -0700
                Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-12 23:15 -0700
              Re: Drop off an if evaluation? John G Harris <niam@jghnorth.org.uk.invalid> - 2020-09-13 11:13 +0100
                Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-13 04:00 -0700
                  Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-13 04:09 -0700
                  Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-13 04:47 -0700
                    Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-13 22:56 -0700
                      Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-14 08:22 -0700
                        Re: Drop off an if evaluation? luserdroog <luser.droog@gmail.com> - 2020-09-14 10:55 -0700
                          Re: Drop off an if evaluation? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-09-14 14:47 -0700

Page 1 of 2  [1] 2  Next page →

#38771 — Drop off an if evaluation?

Is there ways to code so that things that will only be true once, never checked again?

The check dissapear?
I was thinking for things like castling in chess, you only do it once but the code checking for it still accessed for every move? 

[toc] | [next] | [standalone]

#38772

Jonas Thörnvall:

> Is there ways to code so that things that will only be true once, never checked again?
> 
> The check dissapear?

Maybe something like this:

var mycheck = function(x) {
    console.log('Check still executed');
    if(x == true) {
        mycheck = function(x) {
            console.log('Not checking any longer');
            return 1;
        }

        return 1;
    } else {
        return 2;
    }
}

console.log('Run 1 with false');mycheck(false);
console.log('Run 2 with true');mycheck(true);
console.log('Run 3 with false');mycheck(false);
console.log('Run 4 with true');mycheck(true);
console.log('Run 5 with false');mycheck(false);
console.log('Run 6 with true');mycheck(true);

As soon as mycheck() is called with true as parameter, it replaces
itself with another function which will not do any check any more.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38773

On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> Is there ways to code so that things that will only be true once,
> never checked again?
> 
> The check dissapear?
> I was thinking for things like castling in chess, you only do it once
> but the code checking for it still accessed for every move?

You just need a flag that is initially false, and you
check it before checking whether the current position
allows casting: then, when casting, just set the flag
to true.  (Notice that '!casted_already && can_cast()'
will only evaluate can_cast if casted_already is false:
these are called short-circuiting boolean operators.)

More generally, the problem is you are thinking "procedures"
(spaghetti code, actually), while you should be thinking
data structures first, such as an appropriate representation
of the current game state...

Julio

[toc] | [prev] | [next] | [standalone]

#38774

On Friday, 11 September 2020 12:33:14 UTC+2, Julio Di Egidio  wrote:
> On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > Is there ways to code so that things that will only be true once,
> > never checked again?
> > 
> > The check dissapear?
> > I was thinking for things like castling in chess, you only do it once
> > but the code checking for it still accessed for every move?
> 
> You just need a flag that is initially false, and you
> check it before checking whether the current position
> allows casting: then, when casting, just set the flag
> to true.  (Notice that '!casted_already && can_cast()'
> will only evaluate can_cast if casted_already is false:
> these are called short-circuiting boolean operators.)
> 
> More generally, the problem is you are thinking "procedures"
> (spaghetti code, actually), while you should be thinking
> data structures first, such as an appropriate representation
> of the current game state...

(custed_already should be more like custed_already_or_moved,
anyway you get the picture.)

Julio

[toc] | [prev] | [next] | [standalone]

#38776

Julio Di Egidio <julio@diegidio.name> wrote on 11 Sep 2020 in 
comp.lang.javascript:

>> More generally, the problem is you are thinking "procedures"
>> (spaghetti code, actually), while you should be thinking
>> data structures first, such as an appropriate representation
>> of the current game state...
> 
> (custed_already should be more like custed_already_or_moved,
> anyway you get the picture.)

Custard?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#38777

Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > Is there ways to code so that things that will only be true once,
> > never checked again?
> > 
> > The check dissapear?
> > I was thinking for things like castling in chess, you only do it once
> > but the code checking for it still accessed for every move?
> 
> You just need a flag that is initially false, and you
> check it before checking whether the current position
> allows casting: then, when casting, just set the flag
> to true.  (Notice that '!casted_already && can_cast()'
> will only evaluate can_cast if casted_already is false:
> these are called short-circuiting boolean operators.)
> 
> More generally, the problem is you are thinking "procedures"
> (spaghetti code, actually), while you should be thinking
> data structures first, such as an appropriate representation
> of the current game state...
> 
> Julio

I think it is more to the problem "at least in my case" Julio
First i set the 5 options, of casting false.
(R for rock)
kingWhite=false
kingBlack...
shortRblack--
longbRblack--
shortRwhite--
longRwhite--

If king moved you can't cast end of story.
but if not check rock states.

Now my crux i do show the cast positions as soon it is marked.
And i did put the casting together with all other moves because i consider the king move of casting a normal move "but we need a little extra remove/move rock to new position.

Of course those booleans no problem, if we only look at one level, but doing analysis with a tree cascading depth those booleans will take up time?
I can see though that what's below can be wrapped into 
if (whiteCasted==false) 
if (blackCasted=false)

But after i wrap there is still two checks there for every cascading instance of analyse? And they will still be there after I casted, also within your example or do i not understand?


function movePiece(oldMark,t){
        //these are used to see and *set* if piece is moved
	if (oldMark==3){wking_untouched=false;}
	else if (oldMark==59){bking_untouched=false;}
	else if (oldMark==0){wSrockking_untouched=false;}
	else if (oldMark==7){wLrock_untouched=false;}
	else if (oldMark==56){bSrock_untouched=false;}
	else if (oldMark==63){bLrock_untouched=false;}
        //these are used when a king marked "and a potential castling" 
        //can be performed they are set "to true,ready for castling
        //**checks elsewhere"*
	if(WCshort==true){
        //these are where the rock should swap place "king move is treated 
        // just as an ordinary move
        }
	if(BCshort==true){}
	if(WClong==true){}
	if(BClong==true){}
  	drawMove(oldMark,t);
	savePiece=tileElement[oldMark].pieceType;
	savePC=tileElement[oldMark].pieceColor;
	tileElement[oldMark].pieceColor="";
	tileElement[oldMark].pieceType="";
	tileElement[t].pieceType=savePiece;
	tileElement[t].pieceColor=savePC;
	board();
	posMoves.length=0;
	drawNrOfMoves(t);
}

[toc] | [prev] | [next] | [standalone]

#38778

Den fredag 11 september 2020 kl. 19:06:04 UTC+2 skrev Jonas Thörnvall:
> Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> > On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > > Is there ways to code so that things that will only be true once,
> > > never checked again?
> > > 
> > > The check dissapear?
> > > I was thinking for things like castling in chess, you only do it once
> > > but the code checking for it still accessed for every move?
> > 
> > You just need a flag that is initially false, and you
> > check it before checking whether the current position
> > allows casting: then, when casting, just set the flag
> > to true.  (Notice that '!casted_already && can_cast()'
> > will only evaluate can_cast if casted_already is false:
> > these are called short-circuiting boolean operators.)
> > 
> > More generally, the problem is you are thinking "procedures"
> > (spaghetti code, actually), while you should be thinking
> > data structures first, such as an appropriate representation
> > of the current game state...
> > 
> > Julio
> 
> I think it is more to the problem "at least in my case" Julio
> First i set the 5 options, of casting false.
> (R for rock)
> kingWhite=false
> kingBlack...
> shortRblack--
> longbRblack--
> shortRwhite--
> longRwhite--
> 
> If king moved you can't cast end of story.
> but if not check rock states.
> 
> Now my crux i do show the cast positions as soon it is marked.
> And i did put the casting together with all other moves because i consider the king move of casting a normal move "but we need a little extra remove/move rock to new position.
> 
> Of course those booleans no problem, if we only look at one level, but doing analysis with a tree cascading depth those booleans will take up time?
> I can see though that what's below can be wrapped into 
> if (whiteCasted==false) 
> if (blackCasted=false)
> 
> But after i wrap there is still two checks there for every cascading instance of analyse? And they will still be there after I casted, also within your example or do i not understand?
> 
> 
> function movePiece(oldMark,t){
>         //these are used to see and *set* if piece is moved
> 	if (oldMark==3){wking_untouched=false;}
> 	else if (oldMark==59){bking_untouched=false;}
> 	else if (oldMark==0){wSrockking_untouched=false;}
> 	else if (oldMark==7){wLrock_untouched=false;}
> 	else if (oldMark==56){bSrock_untouched=false;}
> 	else if (oldMark==63){bLrock_untouched=false;}
>         //these are used when a king marked "and a potential castling" 
>         //can be performed they are set "to true,ready for castling
>         //**checks elsewhere"*
> 	if(WCshort==true){
>         //these are where the rock should swap place "king move is treated 
>         // just as an ordinary move
>         }
> 	if(BCshort==true){}
> 	if(WClong==true){}
> 	if(BClong==true){}
>   	drawMove(oldMark,t);
> 	savePiece=tileElement[oldMark].pieceType;
> 	savePC=tileElement[oldMark].pieceColor;
> 	tileElement[oldMark].pieceColor="";
> 	tileElement[oldMark].pieceType="";
> 	tileElement[t].pieceType=savePiece;
> 	tileElement[t].pieceColor=savePC;
> 	board();
> 	posMoves.length=0;
> 	drawNrOfMoves(t);
> }

I actually do use "already_casted or moved" checks as booleans for black and white "during when pieces marked" in another function. So "wking and bking untouched" is used elsewhere as well as the rock cases.

[toc] | [prev] | [next] | [standalone]

#38779

On Friday, 11 September 2020 19:06:04 UTC+2, Jonas Thörnvall  wrote:
> Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> > On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > > Is there ways to code so that things that will only be true once,
> > > never checked again?
> > > 
> > > The check dissapear?
> > > I was thinking for things like castling in chess, you only do it once
> > > but the code checking for it still accessed for every move?
> > 
> > You just need a flag that is initially false, and you
> > check it before checking whether the current position
> > allows casting: then, when casting, just set the flag
> > to true.  (Notice that '!casted_already && can_cast()'
> > will only evaluate can_cast if casted_already is false:
> > these are called short-circuiting boolean operators.)
> > 
> > More generally, the problem is you are thinking "procedures"
> > (spaghetti code, actually), while you should be thinking
> > data structures first, such as an appropriate representation
> > of the current game state...
> 
> I think it is more to the problem "at least in my case" Julio

What I said is the ABC of any non-trivial problem actually.

> If king moved you can't cast end of story.
> but if not check rock states.

Whatever, the crucial point is to separate:
- the *game state*;
- the rules of the game (e.g. what moves are available given
  a game state);
- the logic for taking actions (updating the game state: e.g
  the board, who's next, any relevant flags, and what-not);
- the logic for displaying things, again given a game state.
- and so on, e.g. logic to save/load a game (its state)...

And, details apart, the point is: starting from the initial board
configuration, at every move you update the *game state*, and you
keep it separate from the *rules* on a side and from the *actions*
on the other, and even more you keep it separate from the *display*
logic, which is altogether an orthogonal issue which again you
should code generically given a game state: and so on, instead of
"everything along a single pipeline" (aka spaghetti), which
*inevitably* and pretty soon becomes a huge and unmanageable mess.

For more, see Software Engineering 101: Structuring your code...

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#38780

Den fredag 11 september 2020 kl. 20:21:12 UTC+2 skrev Julio Di Egidio:
> On Friday, 11 September 2020 19:06:04 UTC+2, Jonas Thörnvall  wrote:
> > Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> > > On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > > > Is there ways to code so that things that will only be true once,
> > > > never checked again?
> > > > 
> > > > The check dissapear?
> > > > I was thinking for things like castling in chess, you only do it once
> > > > but the code checking for it still accessed for every move?
> > > 
> > > You just need a flag that is initially false, and you
> > > check it before checking whether the current position
> > > allows casting: then, when casting, just set the flag
> > > to true.  (Notice that '!casted_already && can_cast()'
> > > will only evaluate can_cast if casted_already is false:
> > > these are called short-circuiting boolean operators.)
> > > 
> > > More generally, the problem is you are thinking "procedures"
> > > (spaghetti code, actually), while you should be thinking
> > > data structures first, such as an appropriate representation
> > > of the current game state...
> > 
> > I think it is more to the problem "at least in my case" Julio
> 
> What I said is the ABC of any non-trivial problem actually.
> 
> > If king moved you can't cast end of story.
> > but if not check rock states.
> 
> Whatever, the crucial point is to separate:
> - the *game state*;
> - the rules of the game (e.g. what moves are available given
>   a game state);
> - the logic for taking actions (updating the game state: e.g
>   the board, who's next, any relevant flags, and what-not);
> - the logic for displaying things, again given a game state.
> - and so on, e.g. logic to save/load a game (its state)...
> 
> And, details apart, the point is: starting from the initial board
> configuration, at every move you update the *game state*, and you
> keep it separate from the *rules* on a side and from the *actions*
> on the other, and even more you keep it separate from the *display*
> logic, which is altogether an orthogonal issue which again you
> should code generically given a game state: and so on, instead of
> "everything along a single pipeline" (aka spaghetti), which
> *inevitably* and pretty soon becomes a huge and unmanageable mess.
> 
> For more, see Software Engineering 101: Structuring your code...
> 
> HTH,
> 
> Julio

And i said your solution do not change anything, that not is already done.
The cascading if castling statements is unavoidable with your solution.
Just like in mine.

Did see Arnos answer though he seemed to have a solution, "but i did not quite understand the code, have to read it again".

[toc] | [prev] | [next] | [standalone]

#38781

Den fredag 11 september 2020 kl. 20:43:11 UTC+2 skrev Jonas Thörnvall:
> Den fredag 11 september 2020 kl. 20:21:12 UTC+2 skrev Julio Di Egidio:
> > On Friday, 11 September 2020 19:06:04 UTC+2, Jonas Thörnvall  wrote:
> > > Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> > > > On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > > > > Is there ways to code so that things that will only be true once,
> > > > > never checked again?
> > > > > 
> > > > > The check dissapear?
> > > > > I was thinking for things like castling in chess, you only do it once
> > > > > but the code checking for it still accessed for every move?
> > > > 
> > > > You just need a flag that is initially false, and you
> > > > check it before checking whether the current position
> > > > allows casting: then, when casting, just set the flag
> > > > to true.  (Notice that '!casted_already && can_cast()'
> > > > will only evaluate can_cast if casted_already is false:
> > > > these are called short-circuiting boolean operators.)
> > > > 
> > > > More generally, the problem is you are thinking "procedures"
> > > > (spaghetti code, actually), while you should be thinking
> > > > data structures first, such as an appropriate representation
> > > > of the current game state...
> > > 
> > > I think it is more to the problem "at least in my case" Julio
> > 
> > What I said is the ABC of any non-trivial problem actually.
> > 
> > > If king moved you can't cast end of story.
> > > but if not check rock states.
> > 
> > Whatever, the crucial point is to separate:
> > - the *game state*;
> > - the rules of the game (e.g. what moves are available given
> >   a game state);
> > - the logic for taking actions (updating the game state: e.g
> >   the board, who's next, any relevant flags, and what-not);
> > - the logic for displaying things, again given a game state.
> > - and so on, e.g. logic to save/load a game (its state)...
> > 
> > And, details apart, the point is: starting from the initial board
> > configuration, at every move you update the *game state*, and you
> > keep it separate from the *rules* on a side and from the *actions*
> > on the other, and even more you keep it separate from the *display*
> > logic, which is altogether an orthogonal issue which again you
> > should code generically given a game state: and so on, instead of
> > "everything along a single pipeline" (aka spaghetti), which
> > *inevitably* and pretty soon becomes a huge and unmanageable mess.
> > 
> > For more, see Software Engineering 101: Structuring your code...
> > 
> > HTH,
> > 
> > Julio
> 
> And i said your solution do not change anything, that not is already done.
> The cascading if castling statements is unavoidable with your solution.
> Just like in mine.
> 
> Did see Arnos answer though he seemed to have a solution, "but i did not quite understand the code, have to read it again".

Well not it almost do castling correct... So close you will never notice ;)
No i will fix it.

https://jonasth.github.io/chess/chess.html

[toc] | [prev] | [next] | [standalone]

#38782

Den fredag 11 september 2020 kl. 21:18:42 UTC+2 skrev Jonas Thörnvall:
> Den fredag 11 september 2020 kl. 20:43:11 UTC+2 skrev Jonas Thörnvall:
> > Den fredag 11 september 2020 kl. 20:21:12 UTC+2 skrev Julio Di Egidio:
> > > On Friday, 11 September 2020 19:06:04 UTC+2, Jonas Thörnvall  wrote:
> > > > Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> > > > > On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > > > > > Is there ways to code so that things that will only be true once,
> > > > > > never checked again?
> > > > > > 
> > > > > > The check dissapear?
> > > > > > I was thinking for things like castling in chess, you only do it once
> > > > > > but the code checking for it still accessed for every move?
> > > > > 
> > > > > You just need a flag that is initially false, and you
> > > > > check it before checking whether the current position
> > > > > allows casting: then, when casting, just set the flag
> > > > > to true.  (Notice that '!casted_already && can_cast()'
> > > > > will only evaluate can_cast if casted_already is false:
> > > > > these are called short-circuiting boolean operators.)
> > > > > 
> > > > > More generally, the problem is you are thinking "procedures"
> > > > > (spaghetti code, actually), while you should be thinking
> > > > > data structures first, such as an appropriate representation
> > > > > of the current game state...
> > > > 
> > > > I think it is more to the problem "at least in my case" Julio
> > > 
> > > What I said is the ABC of any non-trivial problem actually.
> > > 
> > > > If king moved you can't cast end of story.
> > > > but if not check rock states.
> > > 
> > > Whatever, the crucial point is to separate:
> > > - the *game state*;
> > > - the rules of the game (e.g. what moves are available given
> > >   a game state);
> > > - the logic for taking actions (updating the game state: e.g
> > >   the board, who's next, any relevant flags, and what-not);
> > > - the logic for displaying things, again given a game state.
> > > - and so on, e.g. logic to save/load a game (its state)...
> > > 
> > > And, details apart, the point is: starting from the initial board
> > > configuration, at every move you update the *game state*, and you
> > > keep it separate from the *rules* on a side and from the *actions*
> > > on the other, and even more you keep it separate from the *display*
> > > logic, which is altogether an orthogonal issue which again you
> > > should code generically given a game state: and so on, instead of
> > > "everything along a single pipeline" (aka spaghetti), which
> > > *inevitably* and pretty soon becomes a huge and unmanageable mess.
> > > 
> > > For more, see Software Engineering 101: Structuring your code...
> > > 
> > > HTH,
> > > 
> > > Julio
> > 
> > And i said your solution do not change anything, that not is already done.
> > The cascading if castling statements is unavoidable with your solution.
> > Just like in mine.
> > 
> > Did see Arnos answer though he seemed to have a solution, "but i did not quite understand the code, have to read it again".
> 
> Well not it almost do castling correct... So close you will never notice ;)
> No i will fix it.
> 
> https://jonasth.github.io/chess/chess.html

Fixed castling bug.

[toc] | [prev] | [next] | [standalone]

#38783

On Friday, September 11, 2020 at 1:43:11 PM UTC-5, Jonas Thörnvall wrote:
> Den fredag 11 september 2020 kl. 20:21:12 UTC+2 skrev Julio Di Egidio:
> > On Friday, 11 September 2020 19:06:04 UTC+2, Jonas Thörnvall  wrote:
> > > Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> > > > On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > > > > Is there ways to code so that things that will only be true once,
> > > > > never checked again?
> > > > > 
> > > > > The check dissapear?
> > > > > I was thinking for things like castling in chess, you only do it once
> > > > > but the code checking for it still accessed for every move?
> > > > 
> > > > You just need a flag that is initially false, and you
> > > > check it before checking whether the current position
> > > > allows casting: then, when casting, just set the flag
> > > > to true.  (Notice that '!casted_already && can_cast()'
> > > > will only evaluate can_cast if casted_already is false:
> > > > these are called short-circuiting boolean operators.)
> > > > 
> > > > More generally, the problem is you are thinking "procedures"
> > > > (spaghetti code, actually), while you should be thinking
> > > > data structures first, such as an appropriate representation
> > > > of the current game state...
> > > 
> > > I think it is more to the problem "at least in my case" Julio
> > 
> > What I said is the ABC of any non-trivial problem actually.
> > 
> > > If king moved you can't cast end of story.
> > > but if not check rock states.
> > 
> > Whatever, the crucial point is to separate:
> > - the *game state*;
> > - the rules of the game (e.g. what moves are available given
> >   a game state);
> > - the logic for taking actions (updating the game state: e.g
> >   the board, who's next, any relevant flags, and what-not);
> > - the logic for displaying things, again given a game state.
> > - and so on, e.g. logic to save/load a game (its state)...
> > 
> > And, details apart, the point is: starting from the initial board
> > configuration, at every move you update the *game state*, and you
> > keep it separate from the *rules* on a side and from the *actions*
> > on the other, and even more you keep it separate from the *display*
> > logic, which is altogether an orthogonal issue which again you
> > should code generically given a game state: and so on, instead of
> > "everything along a single pipeline" (aka spaghetti), which
> > *inevitably* and pretty soon becomes a huge and unmanageable mess.
> > 
> > For more, see Software Engineering 101: Structuring your code...
> > 
> > HTH,
> > 
> > Julio
> 
> And i said your solution do not change anything, that not is already done.
> The cascading if castling statements is unavoidable with your solution.
> Just like in mine.

I agree with Julio here. Having a bunch of similarly named variables
like these just screams out for a data structure. Put the complexity
into the data structure and then the code *WILL* be shorter (if you
keep working at it!) and it will be easier to write, read, and 
reason about.

>First i set the 5 options, of casting false.
>(R for rock)
>kingWhite=false
>kingBlack...
>shortRblack--
>longbRblack--
>shortRwhite--
>longRwhite--

It looks like an array at the top level to me, indexed by black=0,
white=1 (or vice versa). 

> Did see Arnos answer though he seemed to have a solution, "but i did not quite understand the code, have to read it again".

Arno's post is also good advice, but you may need a few iteration of
Julio's guidance to get there.

[toc] | [prev] | [next] | [standalone]

#38784

On Saturday, September 12, 2020 at 10:59:08 PM UTC-5, luserdroog wrote:
> On Friday, September 11, 2020 at 1:43:11 PM UTC-5, Jonas Thörnvall wrote:
> > Den fredag 11 september 2020 kl. 20:21:12 UTC+2 skrev Julio Di Egidio:
> > > On Friday, 11 September 2020 19:06:04 UTC+2, Jonas Thörnvall  wrote:
> > > > Den fredag 11 september 2020 kl. 12:33:14 UTC+2 skrev Julio Di Egidio:
> > > > > On Friday, 11 September 2020 08:45:34 UTC+2, Jonas Thörnvall  wrote:
> > > > > > Is there ways to code so that things that will only be true once,
> > > > > > never checked again?
> > > > > > 
> > > > > > The check dissapear?
> > > > > > I was thinking for things like castling in chess, you only do it once
> > > > > > but the code checking for it still accessed for every move?
> > > > > 
> > > > > You just need a flag that is initially false, and you
> > > > > check it before checking whether the current position
> > > > > allows casting: then, when casting, just set the flag
> > > > > to true.  (Notice that '!casted_already && can_cast()'
> > > > > will only evaluate can_cast if casted_already is false:
> > > > > these are called short-circuiting boolean operators.)
> > > > > 
> > > > > More generally, the problem is you are thinking "procedures"
> > > > > (spaghetti code, actually), while you should be thinking
> > > > > data structures first, such as an appropriate representation
> > > > > of the current game state...
> > > > 
> > > > I think it is more to the problem "at least in my case" Julio
> > > 

> I agree with Julio here. Having a bunch of similarly named variables
> like these just screams out for a data structure. Put the complexity
> into the data structure and then the code *WILL* be shorter (if you
> keep working at it!) and it will be easier to write, read, and 
> reason about.
> 

I myself had to undergo this same transition from spaghetti code
to functions and beyond (?). Here's one of my first usenet posts
after starting to relearn programming after a long break.

embarrassing spaghetti code needs stylistic advice  3/19/09
https://groups.google.com/d/topic/comp.lang.c/_m0DEiFqCv0/discussion

Contrast the quality of code there with my more recent code 
for a similar task.

[PC] Simulating Monads, Lambdas, Closures, and Laziness
https://groups.google.com/d/topic/comp.lang.c/8X7r8kacvrA/discussion

The territory has some swamps and obstacles in the middle,
like function spaghetti or all the other pasta monsters. 
But we'll help when you get there. But data structures 
really is the first step out of the babytalk stage of programming
IME. And this is not meant to be insulting. Look at my first
thread. The "embarrassing spaghetti code". It's not *awful* code
in the sense that it's "doing the wrong thing", but it reads like
a storybook instead of a detailed hierarchical table of contents.

The classic book on this is "Structured Programming" by Dahl,
Dijkstra and Hoare. Read Dijsktra's essay. Seriously, read it man.
You won't get it at first, but come back and read it again 
after a week or so. Dahl's article is really good too and goes
into encapsulation, the roots of object orientation. Hoare's 
stuff is great too, but maybe too much to tackle at first.
Dijkstra, dude. We're all in this together. :)

[toc] | [prev] | [next] | [standalone]

#38785

On Saturday, September 12, 2020 at 11:49:47 PM UTC-5, luserdroog wrote:
> 
> The classic book on this is "Structured Programming" by Dahl,
> Dijkstra and Hoare. Read Dijsktra's essay. Seriously, read it man.
> You won't get it at first, but come back and read it again 
> after a week or so. Dahl's article is really good too and goes
> into encapsulation, the roots of object orientation. Hoare's 
> stuff is great too, but maybe too much to tackle at first.
> Dijkstra, dude. We're all in this together. :)

http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF

[toc] | [prev] | [next] | [standalone]

#38786

On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog
<luser.droog@gmail.com> wrote:


  <snip>
>I agree with Julio here. Having a bunch of similarly named variables
>like these just screams out for a data structure. Put the complexity
>into the data structure and then the code *WILL* be shorter (if you
>keep working at it!) and it will be easier to write, read, and 
>reason about.
  <snip>

Putting their advice in as few words as possible :

  Think first
  Code after

  John

[toc] | [prev] | [next] | [standalone]

#38787

Den söndag 13 september 2020 kl. 12:13:12 UTC+2 skrev John G Harris:
> On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog
> <luser.droog@gmail.com> wrote:
> 
> 
>   <snip>
> >I agree with Julio here. Having a bunch of similarly named variables
> >like these just screams out for a data structure. Put the complexity
> >into the data structure and then the code *WILL* be shorter (if you
> >keep working at it!) and it will be easier to write, read, and 
> >reason about.
>   <snip>
> 
> Putting their advice in as few words as possible :
> 
>   Think first
>   Code after
> 
>   John

Putting boolean for movements of individual pieces is just the kind of abstractions "I" try to avoid. I guess though you mean i should use the "tile numbering" to keep track on false and true "moved or not".

For me there is something about write things in cleartext, because then you do not need try figure out what is going on.

Either the thingy is untouched or its not, either the thingy is marked for movement or its not.

Nah abstractions should probably be used where they make things easier lifting and unveil "code" into functional statements, not be used to supress information content into obscure structures whos inhabitants are unknown and unnamed.

Well that is my thought on the subject.

JT 

[toc] | [prev] | [next] | [standalone]

#38788

Den söndag 13 september 2020 kl. 13:00:13 UTC+2 skrev Jonas Thörnvall:
> Den söndag 13 september 2020 kl. 12:13:12 UTC+2 skrev John G Harris:
> > On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog
> > <luser.droog@gmail.com> wrote:
> > 
> > 
> >   <snip>
> > >I agree with Julio here. Having a bunch of similarly named variables
> > >like these just screams out for a data structure. Put the complexity
> > >into the data structure and then the code *WILL* be shorter (if you
> > >keep working at it!) and it will be easier to write, read, and 
> > >reason about.
> >   <snip>
> > 
> > Putting their advice in as few words as possible :
> > 
> >   Think first
> >   Code after
> > 
> >   John
> 
> Putting boolean for movements of individual pieces is just the kind of abstractions "I" try to avoid. I guess though you mean i should use the "tile numbering" to keep track on false and true "moved or not".
> 
> For me there is something about write things in cleartext, because then you do not need try figure out what is going on.
> 
> Either the thingy is untouched or its not, either the thingy is marked for movement or its not.
> 
> Nah abstractions should probably be used where they make things easier lifting and unveil "code" into functional statements, not be used to supress information content into obscure structures whos inhabitants are unknown and unnamed.
> 
> Well that is my thought on the subject.
> 
> JT

Sorry i meant "Putting boolean for movements in of individual pieces in an array is just the kind of abstractions "I" try to avoid.

[toc] | [prev] | [next] | [standalone]

#38789

Den söndag 13 september 2020 kl. 13:00:13 UTC+2 skrev Jonas Thörnvall:
> Den söndag 13 september 2020 kl. 12:13:12 UTC+2 skrev John G Harris:
> > On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog
> > <luser.droog@gmail.com> wrote:
> > 
> > 
> >   <snip>
> > >I agree with Julio here. Having a bunch of similarly named variables
> > >like these just screams out for a data structure. Put the complexity
> > >into the data structure and then the code *WILL* be shorter (if you
> > >keep working at it!) and it will be easier to write, read, and 
> > >reason about.
> >   <snip>
> > 
> > Putting their advice in as few words as possible :
> > 
> >   Think first
> >   Code after
> > 
> >   John
> 
> Putting boolean for movements of individual pieces is just the kind of abstractions "I" try to avoid. I guess though you mean i should use the "tile numbering" to keep track on false and true "moved or not".
> 
> For me there is something about write things in cleartext, because then you do not need try figure out what is going on.
> 
> Either the thingy is untouched or its not, either the thingy is marked for movement or its not.
> 
> Nah abstractions should probably be used where they make things easier lifting and unveil "code" into functional statements, not be used to supress information content into obscure structures whos inhabitants are unknown and unnamed.
> 
> Well that is my thought on the subject.
> 
> JT

The only knowledge/information needed to fully understand my chess it to just write down a flowchart and it even won't be that big. Or better up some JSP chart. You do not even have to understand Javascript programming. Just start with the functions and break them down.

[toc] | [prev] | [next] | [standalone]

#38790

On Sunday, September 13, 2020 at 6:47:52 AM UTC-5, Jonas Thörnvall wrote:
> Den söndag 13 september 2020 kl. 13:00:13 UTC+2 skrev Jonas Thörnvall:
> > Den söndag 13 september 2020 kl. 12:13:12 UTC+2 skrev John G Harris:
> > > On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog
> > > <luser.droog@gmail.com> wrote:
> > > 
> > > 
> > >   <snip>
> > > >I agree with Julio here. Having a bunch of similarly named variables
> > > >like these just screams out for a data structure. Put the complexity
> > > >into the data structure and then the code *WILL* be shorter (if you
> > > >keep working at it!) and it will be easier to write, read, and 
> > > >reason about.
> > >   <snip>
> > > 
> > > Putting their advice in as few words as possible :
> > > 
> > >   Think first
> > >   Code after
> > > 
> > >   John
> > 
> > Putting boolean for movements of individual pieces is just the kind of abstractions "I" try to avoid. I guess though you mean i should use the "tile numbering" to keep track on false and true "moved or not".
> > 
> > For me there is something about write things in cleartext, because then you do not need try figure out what is going on.
> > 
> > Either the thingy is untouched or its not, either the thingy is marked for movement or its not.
> > 
> > Nah abstractions should probably be used where they make things easier lifting and unveil "code" into functional statements, not be used to supress information content into obscure structures whos inhabitants are unknown and unnamed.
> > 
> > Well that is my thought on the subject.
> > 
> > JT
> 
> The only knowledge/information needed to fully understand my chess it to just write down a flowchart and it even won't be that big. Or better up some JSP chart. You do not even have to understand Javascript programming. Just start with the functions and break them down.

That's kinda the crux of the issue right there. The functions should
already be broken down into bite-size pieces with a nice descriptive
name, a clear interface, and no more than 10 lines at most. 

Every time you find yourself writing a long comment about a for loop
or something, a "paragraph" of code, consider wrapping that whole
loop in a function and giving it a name. The name is a "free" comment. And it lets you /collapse/ the for loop and remove it from 
the larger function, making the function smaller and easier to read.

A good function should roughly contain just /one/ syntactic 
construct IMO. One loop. Or one if/else to decide which subfunction
to call. Then you can quickly read each function by itself to see
if it makes sense. And you can spot bugs and problem areas more
easily.

In contrast, with storybook code you have to maintain the whole
saga in your head. You have to remember the exact sequence of
events that led to the calculation of each variable ..., any tweak
in one place can have weird effects elsewhere in the program...

[toc] | [prev] | [next] | [standalone]

#38791

Den måndag 14 september 2020 kl. 07:56:14 UTC+2 skrev luserdroog:
> On Sunday, September 13, 2020 at 6:47:52 AM UTC-5, Jonas Thörnvall wrote:
> > Den söndag 13 september 2020 kl. 13:00:13 UTC+2 skrev Jonas Thörnvall:
> > > Den söndag 13 september 2020 kl. 12:13:12 UTC+2 skrev John G Harris:
> > > > On Sat, 12 Sep 2020 20:59:00 -0700 (PDT), luserdroog
> > > > <luser.droog@gmail.com> wrote:
> > > > 
> > > > 
> > > >   <snip>
> > > > >I agree with Julio here. Having a bunch of similarly named variables
> > > > >like these just screams out for a data structure. Put the complexity
> > > > >into the data structure and then the code *WILL* be shorter (if you
> > > > >keep working at it!) and it will be easier to write, read, and 
> > > > >reason about.
> > > >   <snip>
> > > > 
> > > > Putting their advice in as few words as possible :
> > > > 
> > > >   Think first
> > > >   Code after
> > > > 
> > > >   John
> > > 
> > > Putting boolean for movements of individual pieces is just the kind of abstractions "I" try to avoid. I guess though you mean i should use the "tile numbering" to keep track on false and true "moved or not".
> > > 
> > > For me there is something about write things in cleartext, because then you do not need try figure out what is going on.
> > > 
> > > Either the thingy is untouched or its not, either the thingy is marked for movement or its not.
> > > 
> > > Nah abstractions should probably be used where they make things easier lifting and unveil "code" into functional statements, not be used to supress information content into obscure structures whos inhabitants are unknown and unnamed.
> > > 
> > > Well that is my thought on the subject.
> > > 
> > > JT
> > 
> > The only knowledge/information needed to fully understand my chess it to just write down a flowchart and it even won't be that big. Or better up some JSP chart. You do not even have to understand Javascript programming. Just start with the functions and break them down.
> 
> That's kinda the crux of the issue right there. The functions should
> already be broken down into bite-size pieces with a nice descriptive
> name, a clear interface, and no more than 10 lines at most. 
> 
> Every time you find yourself writing a long comment about a for loop
> or something, a "paragraph" of code, consider wrapping that whole
> loop in a function and giving it a name. The name is a "free" comment. And it lets you /collapse/ the for loop and remove it from 
> the larger function, making the function smaller and easier to read.
> 
> A good function should roughly contain just /one/ syntactic 
> construct IMO. One loop. Or one if/else to decide which subfunction
> to call. Then you can quickly read each function by itself to see
> if it makes sense. And you can spot bugs and problem areas more
> easily.
> 
> In contrast, with storybook code you have to maintain the whole
> saga in your head. You have to remember the exact sequence of
> events that led to the calculation of each variable ..., any tweak
> in one place can have weird effects elsewhere in the program...

I do not know whatever piece of my code you think off because there is hardly any function over 10 lines except for board initiation, and almost all use the loops to call other functions after a new assignment.

Where are those giant functions you speak off?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web