Name: android-style-guide
Owner: Droids On Roids
Description: null
Created: 2017-03-27 06:01:05.0
Updated: 2017-10-31 10:46:28.0
Pushed: 2017-04-24 06:57:40.0
Homepage: null
Size: 7
Language: null
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Every DOR Android team member should use this code formatting style in Android Studio:
dor-android-studio-code-style.xml
This ensures formatting consistency across projects. It also makes code review more pleasant, as it reduces time spent on checking things like missing spaces, wrong indents, etc.
SonarQube is a code inspection tool that helps you:
It won't break your builds, but it will judge you and your code by commenting your commits uploaded for review.
You can also run SonarQube locally in your project without waiting for a remote build to complete. See the official guide for reference:
Analyzing with SonarQube Scanner for Gradle
SonarLint is an Android Studio plugin. It can connect to an external SonarQube server and analyze code on-the-fly, similar to the built-in default Lint functionality.
I think you can handle the plugin config within Android Studio.
If it doesn't work out of the box, you'll have to use a different JDK with JCE unlimited strength policy:
install the newest JDK
Homebrew: brew install Caskroom/cask/java.
install JCE Unlimited Strength Policy
brew install Caskroom/cask/jce-unlimited-strength-policy
select the JDK version used by Android Studio
Go to ~/Library/Preferences/AndroidStudio2.3/studio.jdk (if it doesn't exist, just create a new one).
Add the following line /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk.
Make sure to use change use your current version numbers.
restart Android Studio
There is no strict code style that you have to follow. Instead, please refer to some good existing ones:
Solid general Java style to follow.
Good Java and Android-specific practices - apart from Hungarian notation.
Similar to Ribot's.
A successful XML naming convention
Good convention for naming Android resource files.
The only rule you should go by is to be consistent within a project.
Please refer to Kotlin's website: Kotlin Coding Conventions
Kotlin Android Extensions automatically bind XML-defined views. This allows us to call them through synthetic properties without manually using findViewById() or Butterknife.
Considering that, use lowerCamelCase when naming views in XML files (in contrast to snake_case in Java projects).
When naming tests, use backticked method names for better readability:
Methods with braces or as assignment?
he method body is simple or short enough to fit in the same line, use the **assignment operator ( = )**, otherwise use **braces ( { } )**.
Loops or streams?
ider streams when iterating (instead of typical for loops), as they can often make the code more concise and readable.
Hungarian notation
arian notation (private/static fields starting with m/s) is generally **not recommended**. Here's a good write-up on why not:
t Say mNo to Hungarian Notation (Jake Wharton)](http://jakewharton.com/just-say-no-to-hungarian-notation/)
ou wish to easily remove it from an existing project, see this article about the **Structural Search and Replace** feature of Android Studio:
roid Studio Like a Boss (Realm.io)](https://realm.io/news/360andev-philippe-breault-android-studio-ide-like-boss-structural-search-refactoring-java/)
RxJava/Stream chains
e can get pretty ugly sometimes.
ossible, avoid deep nesting in RxJava/Stream chains. Instead, try to refactor operator arguments into separate methods. A good rule of thumb for clean and readable chains: **one line = one operator**.