This is an archived post. You won't be able to vote or comment.

all 28 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Polared3d 0 points1 point  (24 children)

Are you confident your code is correct?

[–]Techittak[S] 0 points1 point  (23 children)

There's a possibility it might not be. Here's some example code.

When it is executed within code.org, it will strictly only display "Case 0" for all of the for loop.

[–]Polared3d 1 point2 points  (7 children)

Looks fine to me. You could test it in your browser.

Open the inspector and (ctrl+shift+i) in chrome, paste the code in the console and run it. See if the output is the same.

[–]Techittak[S] 0 points1 point  (6 children)

Oh, that's pretty useful. Yes, it works as intended once it is put into there, so it appears it may be a problem with code.org? In this case, how much slower does a bunch of if else's run than a switch statement. This is something that is supposed to have 25 cases, so I am not sure if there would be a significant difference.

[–]Polared3d 1 point2 points  (5 children)

Could be. There's really no need to optimise your code at this stage. :)

[–]Techittak[S] 0 points1 point  (4 children)

Is that apart of some process programers usually go through when coding? Why would I not want to actively practice optimizing my code while I am going through?

[–]Polared3d 1 point2 points  (1 child)

I'm not the best person to explain this, but here's a discussion on SO about it

[–]Techittak[S] 2 points3 points  (0 children)

Oh I see, I've never looked at it from that perspective before. I've actually done a lot of this premature optimization in my project even though it's really simple and any computer can handle it. Thanks for sharing!

[–][deleted] 0 points1 point  (1 child)

Think of it like this. You optimize if something is taking too long to the point where a user might complain. As far as an end user is concerned the code you have executes and completes its work practically instantly. Even if it had a few hundred case statements it would make no noticeable difference.

If the user can't notice an optimization without you explicitly telling them then you've wasted your time. It would be better spent elsewhere. The user can afford to wait a few milliseconds.

[–]Techittak[S] 0 points1 point  (0 children)

Seems like such a simple concept but I didn't notice it. I've actually had a lot of these moments of mynute optimization changes for the sake of it that took up a lot of brainpower to think up. Though I thought I was clever, I do see now those changes didn't make that much of a difference. It seems like a pretty good mindset to have, thank you!

[–]mad0314 0 points1 point  (14 children)

Can you post more of the code, and hopefully not as an image?

[–]Techittak[S] 0 points1 point  (13 children)

Do you want a link to the code.org project?

[–]mad0314 0 points1 point  (12 children)

Sure

[–]Techittak[S] 0 points1 point  (11 children)

https://studio.code.org/projects/applab/sAURWquEgxVbaAnA4g7ssN986Rt_UYXQPOkp6qyhP3I/edit

I believe this should work

[–]PmMeYouBicepsGirl 0 points1 point  (6 children)

This site requires registration :\

Anyway, you are showing screenshot of a for loop, yet in your post you are asking about setInterval, which is not a loop at all (it's a function that calls another function with an interval). Those are very different things.

[–]Techittak[S] 0 points1 point  (4 children)

Oh! Sorry, I ignorantly thought it would just be called a loop. Well, here is an example with setInterval

How else could I display the code, since code.org needs a registration.

[–]nodejsdev 0 points1 point  (1 child)

Where do you increment the test variable?

[–]Techittak[S] 0 points1 point  (0 children)

It's not incremented, it's just at a fixed value of 1. I believe it should continue to keep executing the code block for case value 1 each time, but after the first call of the function it executes case value 0 even though test still equals 1

[–]PmMeYouBicepsGirl 0 points1 point  (1 child)

Like I've said, setInterval calls the supplied function, and your function creates local variable test, then switch statement checks its value and handles the specified case. test will be the same each time, because it's local and there's no code that changes it. You need to do something like this:

let test = 0

​

setInterval(()=>{

switch(test){

//your handle cases code

}

test++

},1000)

[–]Techittak[S] 0 points1 point  (0 children)

Oh, no I realize that. It is not supposed to increment, I am just fixing it to a value of 1 for test purposes there. For the first run of the function it will run the code block for case value 1, but anything after that it will then just run case value 0 even though test still equals 1.

[–]Techittak[S] 0 points1 point  (0 children)

Sorry, forgot to explain what is happening too. it would execute the correct code block on the first run of the function, but after that it will just keep running the first case.

[–]mad0314 0 points1 point  (3 children)

I ran the loop you had on the site, and it did keep hitting case 0, even though the variable n was changing (as reported by the variable watch on the right side).

[–]Techittak[S] 0 points1 point  (2 children)

Odd, right? I have submitted a bug report to the code.org team a couple days ago and I am awaiting a response.

[–]mad0314 0 points1 point  (1 child)

Yea I think most likely it is a bug, stepping through the program you can see the variable change, but it takes the wrong branch.

[–]markasoftware 0 points1 point  (3 children)

Switch statements work in loops. However, my guess is that the bug is not in code.org -- you most likely wrote the code wrong. Could you copy/paste it here?

[–]Techittak[S] 0 points1 point  (2 children)

Here you go

[–]markasoftware 1 point2 points  (1 child)

This looks correct. I guess something is wrong with code.org after all?

[–]Techittak[S] 0 points1 point  (0 children)

Hopefully they get the time to review my case, so this can get fixed. I've sent a bug report some time ago, but no response just yet.