Project Rules and Guidelines

This page discusses the required code conventions & work etiquette for pushing code to YP5779/team1. The code conventions are all-encompassing. Meaning, both tests, and code must adhere to them

Code Conventions

• Spartanization - all code being push must be completely spartanized and contain no tips

• No Warnings - Code must have no explicit warnings

• Boxing - using functions such as Integer.valueOf(1) or Integer.intValue() are forbidden. Instead, use the classes box & unbox the project provides whenever possible. Special cases are functionalities that box cannot provide such as casting a string to an Integer. In this case, please see other useful utility classes we offer, such as string. Also, if possible use box.it(.) or use static import in order to write box(.) since it is cleaner.

• Assertions - The class azzert must be used whenever possible. The assert keyword may only be used when asserting the value of a boolean expression. Also, it is preferable to use the fluent API offered by azzert. e.g.: azzert.that(L.length(), is(4)) rather than assert L.length() == 4 and certainly rather than assert.assertEquals(L.length(), 4) which is considered forbidden.

• @SuppressWarnings("static-method") - can only occur in the class definition, not on every test method.

• @SuppressWarnings("static-access") - should not be present at all. Using the azzert fluent API will not result in such warnings.

• @SuppressWarnings("null") - Use Utils.canBeNull() or Utils.cantBeNull() in order to conform to @Nullable T or @NotNull T. Or, use @Nullable and @NotNull yourselves in the variable decleration.

• @SuppressWarnings("unused") - should not occur, the utility interface forget can help eliminate such warnings. Meaning, if x is unused then simply call forget.it(x).

As a general rule, warning suppression is the last resort and must only when all other options were exhausted.

General Work Etiquette

• Commit Messages - commit messages must be indicative of the specific change made by each commit. For instance, a series of commits with an identical, general commit message such as "Finished class X" is forbidden since it is unclear what each commit contributed.

• State of Code - Code being pushed must be complete (not partial) and must pass all tests. Do not push partial code, commit it locally instead.

• Milestones - each issue must have a milestone present. Please, make sure that all the issues you are assigned to belong to a milestone. This applies both for closed and open issues.

• Reviews - All non-trivial issues must be reviewed before closing. The review process is as follows: The assigned team member will label the issue with the label Needs review (of a cornflower blue color). Then, a different team member will review it. If the code is accepted then the label is removed and the issue is closed (by the reviewer! to show his seal of approval). The reviewer must comment on the issue a statement gesturing his approval of the code (for tracking down purposes). Otherwise, the code is labeled with the red Rejected label and will be re-reviewed at a later date (not necessarily by the same person). Lastly, code deviating from the previously stated code conventions will NOT be accepted (please be cautious to violations as reviewers and code writers). Should include a reference to #79

• Assignees - each issue must have a team member assigned to it. If you see an issue without a team member assigned to it for quite some time then please assign yourselves or remind the team of the issue.

• Duplicates - all duplicated issues must be marked accordingly with the label duplicate and a comment saying "duplicate of #..."

• Personal Progress - must be updated regularly with issues performed by each team member. Firstly, person X's personal progress must have the correct title, be labeled properly and easy to understand. It may not include duplicate issues! Also, it may only contain issues to which the person is assigned, deviations must be resolved. For instance, if person X wishes to list an issue of person Y (to which X is not assigned) then X must ask Y to assign him to the issue, explain why it is deserved and then lastly comment on the issue at hand what was X's contribution.

Addendum

All changes to this document must be approved by the team based on a voting system to be determined. Also, all team members must read this document fully and agree explicitly to adhere to the guidelines described.