Issue:
In our score code we use refactored logic that does not explicitly follow the documented rules.
For example, when calculating the players score we use negative logic, e.g. player.action != actions.BRAKE , while in the documentation we define the rules using positive language, e.g. if you want to continue forward. return actions.RIGHT or actions.LEFT if you like to bypass the obstacle.
There are reasons why you might want to follow the document's logic explicitly rather than refactoring it:
Clarity and Traceability: If someone else (or even you at a later time) refers back to the original documentation to understand or validate the code's behavior, having the logic implemented as closely as possible to the documented rules makes it easier to follow and validate.
Avoid Introduction of Bugs: Sometimes refactoring can introduce unintended side effects, especially when the original rules have been tested and validated extensively.
Maintenance and Future Updates: If the documentation is updated in the future, it's much easier to identify what parts of the code need to change if the code follows the structure of the documentation.
Communication with Stakeholders: If you're communicating with non-technical stakeholders who are familiar with the documented rules but not with the nuances of code, it helps if your code closely mirrors the documentation. This can make discussions and explanations smoother.
In our case, ROSE is intended as educational code for students learning to code, it makes sense to write the score code to explicitly follow the documented rules.
What are the updates proposed by this PR:
Use positive logic to follow the documentation, e.g. replace the != with == and not in with in
Use score_pickup explicitly, instead of using score_move_forward
When moving backword use `score_move_backward instead of addingscore_move_forward and then reducingscore_move_backward` twice.
Move action clean up to the end of the method
Remove six
Possible bug fixes:
Current code assume score_move_backward and score_move_forward are identical, if they will change current code logic will break.
Currnet code assumes score_move_forward and score_pickup are identical, if they change current code will break.
Issue: In our score code we use refactored logic that does not explicitly follow the documented rules.
For example, when calculating the players score we use negative logic, e.g.
player.action != actions.BRAKE
, while in the documentation we define the rules using positive language, e.g.if you want to continue forward. return actions.RIGHT or actions.LEFT if you like to bypass the obstacle.
There are reasons why you might want to follow the document's logic explicitly rather than refactoring it:
Clarity and Traceability: If someone else (or even you at a later time) refers back to the original documentation to understand or validate the code's behavior, having the logic implemented as closely as possible to the documented rules makes it easier to follow and validate.
Avoid Introduction of Bugs: Sometimes refactoring can introduce unintended side effects, especially when the original rules have been tested and validated extensively.
Maintenance and Future Updates: If the documentation is updated in the future, it's much easier to identify what parts of the code need to change if the code follows the structure of the documentation.
Communication with Stakeholders: If you're communicating with non-technical stakeholders who are familiar with the documented rules but not with the nuances of code, it helps if your code closely mirrors the documentation. This can make discussions and explanations smoother.
In our case, ROSE is intended as educational code for students learning to code, it makes sense to write the score code to explicitly follow the documented rules.
What are the updates proposed by this PR:
!=
with==
andnot in
within
score_pickup
explicitly, instead of usingscore_move_forward
`score_move_backward instead of adding
score_move_forwardand then reducing
score_move_backward` twice.Possible bug fixes:
Ref: https://github.com/RedHat-Israel/ROSE/tree/master/examples