When you will be professionnals, you will be working in teams, sharing your code with others. As a consequence, you cannot write code as if you were alone. You have to take into consideration that others (potentially less qualified) will have to read/understand/modify your code. Even when coding alone, you will frequently have to modify your own code some time after writing it (to correct bugs, adapt to new library version, etc.).
That's why Good Coding Practices have been developped along the years by professional programmers: To help you directly write code that is easier to understand and modify. And facilitate your colleagues (or future-self)'s job.
That's also why, during your projects, we will ask you to respect as much as possible the Good Coding Practices listed in this file (here, we will use rules defined in the - very pratical and easy to read - book "Java by Comparison").
At least, during your projects, you MUST respect the following rules (your evaluation will take them into account):
-
General
- Rule#5 (always check for null - args...)
- Rule#8/Rule#14 (group code that goes together / indent)
- Rule#72 (log in file rather than console)
- Rule#11 (favor for-each)
- Rule#15 (use string format)
- Rule#68 (define code style for the whole team)
-
Comments
- Rule#21 (=template)
-
Naming
- Rule#29 (select good names)
-
Exceptions
- Rule#34 (catch most specific Exception)
- Rule#39 (close resources)
-
Testing
- Rule#42 (=template)
- Rule#50 (treat edge cases)
-
Design
- Rule#54 (favor immutable)
-
Java8
- Rule#64 (use optionals rather than nulls)