xthx7q
Last Updated: February 25, 2016
·
2.13K
· raulraja
Ad2476bf0540dfaa0fc30cb62c8e07da

Java Coding Guidelines

We have open sourced our coding guidelines for Java, Android, Spring and other Java related frameworks for all members in our team to be in the same page. Here they are in case anyone finds it useful.

https://github.com/47deg/coding-guidelines/tree/master/java

Say Thanks
Respond

4 Responses
Add your response

114
130921 tcl 103 s

My preference is to use descriptive names over comments. No comments is better than wrong, outdated comments. I like to let the my codes speak for themselves.

Whenever I come across codes with single return statements, I am obligated to read them to the end even after I locate the relevant condition/guard clause. I think those annoying long-lived local variables are actually more time-consuming to debug..

over 1 year ago ·
327
Ad2476bf0540dfaa0fc30cb62c8e07da

Ivan,

Great points. I agree that descriptive names are necessary. As for the comments is mostly so they may be included automatically as part of the java docs and to provide a further explanation of what the code is doing or how it is implemented.

In regards to long methods and their multiple rerun statements I do prefer to not have long methods and a single return as show here https://github.com/47deg/coding-guidelines/tree/master/java#56-private-helpers . Cheers

over 1 year ago ·
5262
Ecfbafac465b2c144a6922c98476a412

My only thoughts about android guidelines:
Dividing all the packages for activities/services/fragments/etc may be okay at the beginning but when your application is growing more and more I would rather go for "package by feature" instead of "package by layer". Naming packages like "users" or "posts" makes your app more modular. This makes you able to track (for example) circular dependencies between modules. Additionally, removing some functionality from the app is a lot easier when all the classes related to that specific feature are condensed in one package. Otherwise it's (too) easy to forget about some single fragment/helper/something that is not needed anymore.
Anyway, it's rather hard to disagree with anything else, especially the java-in-general guidelines so great thanks to you guys. :-)

over 1 year ago ·
5263
Ad2476bf0540dfaa0fc30cb62c8e07da

Partition,

Thanks for your input. I agree with you that in some cases is more efficient and natural a "package by feature" approach. The reason why do it by layer is that In our largest Android project, a framework that we use to bootstrap app development internally, there is no concrete model thus the more natural way for us to follow infrastructure principles than grouping based on features.

over 1 year ago ·