Google Java Best Practices Summary
Google Java Best Practices Summary
The guide emphasizes adhering to the DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid) principles to reduce redundancy and complexity in code. It also advises avoiding magic numbers by using constants, which enhances readability and maintainability. Writing unit tests for logic branches is another strategy encouraged to ensure that code is robust and error-free .
The document prefers using List over ArrayList in declarations to promote programming to interfaces rather than specific implementations. This practice provides flexibility, allowing the code to be more easily adapted to use different List implementations without changing the codebase. It adheres to the Liskov Substitution Principle of object-oriented programming .
The guide recommends that methods be short and focused, ideally no longer than 40 lines, with clearly specified visibility (public/private, etc.). Methods should have descriptive naming patterns such as calculateSum(), instead of vague or concise identifiers like c(). These guidelines promote greater readability, easier debugging, and maintaining single-function responsibility, which is crucial in adhering to the principles of clean code .
The document recommends using tools and linters such as Checkstyle and Error Prone for ensuring adherence to coding standards and detecting common bugs. It also suggests using AutoValue, Guava, Truth, and JUnit for their utility in creating robust Java applications. These tools are recommended to automate code style enforcement and enhance overall code quality by catching potential errors at early stages .
Google Java Best Practices recommend catching specific exceptions rather than general ones like Exception or Throwable. Errors should be logged rather than swallowed to ensure that they are not silently ignored. Additionally, try-with-resources should be used for Automatic Resource Management on AutoCloseables to prevent resource leaks .
According to Google Java Best Practices, classes and interfaces should use UpperCamelCase (e.g., MyServiceManager). Methods and variables should use lowerCamelCase (e.g., getUserData). Constants should be named using UPPER_UNDERSCORE (e.g., MAX_RETRY_COUNT). Package names should be lowercase and should not contain underscores (e.g., com.google.auth).
The guide advises using concurrent utilities such as Executors and ConcurrentHashMap to manage concurrency and avoid using synchronized blocks unless they are absolutely necessary. This is to help maintain thread safety without incurring the performance overhead often associated with synchronized methods .
The document stresses the use of Javadoc for documenting public APIs, which aids in generating clear and helpful documentation for users of the code. Comments should be meaningful yet concise, aiming to provide clarification without redundancy or clutter. This enhances the coding experience by making the code more understandable and maintainable for future developers .
The document recommends using a 2-space indentation to improve readability and prevent excessive nesting. Braces should be used on the same line as control flow statements for consistency. Avoiding wildcard imports promotes clarity in knowing exactly what is being included within a file. These practices contribute to a cleaner and more maintainable codebase .
The guide advises avoiding returning null values and instead using the Optional class, which forces handling of the potential absence of a value and helps prevent NullPointerExceptions. It also advocates using Objects.requireNonNull() for input validation to ensure that method parameters and fields in classes meet expected conditions. These practices aim to enhance the robustness and clarity of the code, reducing runtime errors caused by null references .