Alibaba Java Development Manual: Essential Coding Style Guidelines for Beginners
This article presents a comprehensive set of mandatory and recommended Java coding style rules—including brace placement, spacing, indentation, line length, comment formatting, naming conventions, and best‑practice recommendations—extracted from the Alibaba Java Development Manual to help junior developers write clean, readable code.
As a programmer, writing tidy code is essential, so this article shares useful basic coding conventions for junior developers found in the "Alibaba Java Development Manual".
1. Braces: Empty blocks use {}, non‑empty blocks: no line break before the opening brace, line break after it, line break before the closing brace, and no line break after the closing brace if followed by else.
2. No spaces between parentheses and identifiers. Example of a bad case: if ( a == b ) .
3. Keywords such as if/for/while/switch/do must have a space before the opening parenthesis.
4. Binary and ternary operators must have a space on both sides.
5. Use four spaces for indentation and never use tab characters. Configure IDEs (IDEA, Eclipse) accordingly.
6. Single‑line comments must have exactly one space after the //.
7. Limit a line to 120 characters; when exceeding, wrap with a 4‑space indent and follow specific rules for operators, method calls, and commas.
8. In method parameter lists, place a space after each comma. Example: method("a", "b", "c");
9. Set file encoding to UTF‑8 and use Unix line endings.
10. Avoid adding extra spaces solely for visual alignment.
11. Insert a blank line between distinct logical blocks (e.g., different business logic sections).
12. Access static members via the class name, not an instance.
13. Do not use deprecated classes or methods. Example: replace java.net.URLDecoder.decode(String) with the two‑parameter version.
14. Call equals on a constant or non‑null object to avoid NullPointerException. Use "test".equals(obj) instead of obj.equals("test") .
15. Compare wrapper class values using equals , not == , except for cached Integer range.
16. Constructors should contain no business logic; place initialization in a separate init method.
17. POJO classes must override toString for easier debugging.
18. When using String.split , check the length of the resulting array to avoid IndexOutOfBoundsException.
19. Group overloaded constructors or methods together for readability.
20. Order class methods as: public/protected, then private, then getters/setters.
21. In setters, use this.field = field and avoid adding business logic.
22. Use StringBuilder.append inside loops instead of string concatenation.
23. Apply the final keyword to classes, fields, methods, and local variables where appropriate.
24. Array brackets are part of the type declaration (e.g., String[] args ).
25. Do not prefix boolean fields with "is" in POJOs to avoid serialization issues.
26. Extract complex conditional logic into well‑named boolean variables for clarity.
27. Always use braces for if/else/for/while/do blocks, even for single statements.
28. Repeat the recommended method ordering (public/protected, private, getters/setters) for consistency.
These guidelines aim to improve code readability, maintainability, and reduce bugs across Java projects.
Java Captain
Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.