Java Coding Guidelines

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..

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

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. :-)

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.