Refactor Variable Names In Canvas Record Classes

[Maillman]

Overview

Some of the variable names in some of the record classes in the canvas package don't follow the standard Java naming convention. The reason for this is that we use these classes to deserialize the result that Canvas gives us, and the fields Canvas provides are in lower_snake_case.
This can potentially cause some confusion to someone who understands the Java naming convention but does not understand that these classes are used for deserialization, and they may attempt to refactor the variable names without realizing that doing so will cause an issue with deserialization.

Examples

Here are some examples of some of the record classes that have this issue:

autograder/src/main/java/edu/byu/cs/canvas/model/CanvasAssignment.java

Lines 14 to 19 in db56729

	public record CanvasAssignment(
	Integer id,
	String name,
	ZonedDateTime due_at,
	List<CanvasRubric> rubric
	) {

autograder/src/main/java/edu/byu/cs/canvas/model/CanvasSection.java

Line 19 in db56729

public record CanvasSectionStudent (String login_id) {}

autograder/src/main/java/edu/byu/cs/canvas/model/CanvasSubmission.java

Line 10 in db56729

public record CanvasSubmission(String url, CanvasRubricAssessment rubric_assessment, Float score) {}

Note that this may not be all of the classes that have this issue; there may be more.

Solution

A solution to this problem is already present elsewhere in the autograder (or at least should be sometime after this issue is created), and it using the @SerializedName annotation from Gson. This may not be the only solution, but if it is already being used elsewhere in the autograder, then it is best to keep consistency and use this solution.

Additional Notes

There may be some other variable names that don't follow the standard Java naming convention outside of the canvas package. You can find these using a static analysis tool like the built-in one for IntelliJ, or some other external source such as SonarQube.
Whenever you find these variable names that don't follow the standard Java naming convention, please try to understand the reason why it followed that naming convention, if any. And do testing to ensure that your refactoring didn't break anything. Good luck!