INDIVIDUALLY, interpret the results of the comparison and boolean operator statements AS A GROUP, compare your results with each other and discuss any answers that do not match Where did you encounter struggles? What did you do to deal with it? Add any additional reflections on what you learned in this station.
|I started encountering struggles when I moved onto the second slide. Since I don’t memorize the value of ASCII characters, I had to use the website below to determine the numerical value of the characters. I then had to use these values and compare them to others. I found it helpful to work on one side at a time. For example in A, I would I would figure out if the left side of
|was true or false. Then I would find the result of the right side. After getting the two values, I could see whether it was
|or && and conclude if the line was true or false. For the third slide, I again had to find the values of the ASCII characters. I worked from left to right and the inside out. This helped me remember which operators I’ve already utilized. This station has shown me that there are many ways to have an output of true or false. It has also shown me how important where I put my operators was as well. By misplacing ! I could have the opposite result of what I would want.
INDIVIDUALLY, fill out the trace tables by writing the value for each variable when it is outputted to the screen (System.out.println) AS A GROUP, compare your results with each other and discuss any values that do not match in the tables What is the hardest part of tracing code? Why is learning how to trace code important? Add any additional reflections on what you learned in this station.
The hardest part about tracing code ensuring that you don’t make mistakes that affect the rest of the results. An example of this would be on the last slide. If I for some reason determined that x%0 did not equal 0. I would have a different y value. This in turn would result in the rest of my y values being incorrect. I believe that learning to trace code is important because it can help diagnose where an issue could be. If a program was outputting the wrong result, the programmer could trace the code to find out what is causing the error. This station also has reminded me that not all of the code in a program needs to be utilized. The else statement in the fourth slide isn’t used, and I thought I was doing something wrong. After double checking my traces, I concluded that x would keep landing inside the if condition. This could be helpful when programming as you could use the if statement for expected results and the else for errors.
Review the code and pretend you’re a compiler by:
- fixing the code
- adding your OWN custom compiler message
Which syntax error did you have a hard time finding? Why? Add any additional reflections on what you learned in this station.
The syntax error that I had a hard time finding was the args in the first slide and the two semicolons in the second slide. Since Replit usually creates the first two lines of code, I wouldn’t think there would be an error located in those lines. I don’t touch either of those lines as with my current knowledge of Java, I don’t need to. I learned that I shouldn’t take any code for granted and should look through all the code, pregenerated and written. This may help me diagnose any issues that I would overlook. The semicolons in the second slide also caught me off guard. Since both of them were replaced with commas, I didn’t immediately see the issue. I’m not sure if my dip into Python made me overlook the commas, but I eventually remembered that you need to use semicolons. This has also shown me that I should not try to learn too many languages at once. My learning of Java and Python at the same time has made me dull at both and focusing on Java alone could’ve helped with finding errors like these.
AS A GROUP, construct the code to match the output provided Which type statements were the hardest to construct? Why? Add any additional reflections on what you learned in this station.
|The statements that were hardest to construct were the if and else if statements. Usually when I use these statements, I set a range of numbers such as (score >= 80
|score < 90). These station didn’t set an upper limit, and that threw me off. I had never considered that I could just use the first part of my condition to produce the same result. This exercise has shown me that I could make my code shorter and easier to read by cutting back on the redundant part of conditions. This could especially prove helpful with multiple else if statements, though I do prefer to set an upper limit on my conditions.