1) Tous les identifiants sont en CamelCase (les mots sont attachés, chaque mot commence par une majuscule). Le caractère “_” (underscore) est interdit (sauf constantes voir #7).

2) Le premier mot des identifiants de types (classes, enum, interface) commence avec une majuscule (voir points #3 et #4). Les autres identifiants commencent par une minuscule, que ce soient des variables (voir points #5 et #6) ou des fonctions.

3) Toujours commencer le nom d'une interface par la lettre I.

4) Toujours commencer le nom d'une classe abstraite par Abstract. Pour ne pas avoir de nom à rallonge, ce nom peut commencer par la lettre A.

5) Les membres de classe non statiques doivent commencer par un ‘m' et/ou précéder l'utilisation d'un membre de classe par “this”, le but étant de pouvoir les différencier des variables locales.

6) Les membres de classe statiques non final doivent commencer par un ‘s'.

7) Les variables de type public static final doivent être en majuscules. De plus, le nom de la variable contenant plusieurs mots doit séparer ces derniers par un underscore :

public static final String MON_NOM_DE_VARIABLE_STATIC_FINAL;

8) Les noms de variables doivent commencer par une minuscule.

9) Les noms de fonctions doivent être explicites. Nous devons savoir ce que fait une fonction sans même lire le code.

De même, les noms de variables doivent aussi être explicites. Il faut favoriser les noms discriminants.

Les identifiants XML ne doivent pas contenir de majuscule. La bonne pratique consiste à remplacer la majuscule par une minuscule précédée d'un tiré bas. Par exemple, “monIdentifiant” devient “mon_identifiant”.

Il faut éviter les doublons au niveau des identifiants. Une pratique pour cela peut être de préfixer l'identifiant par le fichier de layout.

Les identifiants XML commencent par une minuscule.

Astuce : Les fichiers de ressource des layout sont souvent difficiles à retrouver parmi nos dizaines de fichiers. Il est préférable de préfixer le nom du fichier de ressource par le type de layout. Par exemple :

- Un fichier de ressource pour une activité sera préfixé par “activity_” suivi du nom de l'activité l'utilisant. Si l'activité est “AuthenticationActivity.java”, le layout sera “activity_authentication”.

- Un fichier de ressource pour un fragment sera préfixé par “fragment_” suivi du nom du fragment l'utilisant. Si le fragment est “ListEtudiantFragment.java”, le layout sera “fragment_list_etudiant”.

- Un fichier de ressource pour une vue sera préfixé par “view_” suivi du nom de la vue l'utilisant. Si la vue est “MyCardView.java”, le layout sera “view_my_card”.

- Un fichier de ressource pour un item sera préfixé par “item_” suivi du type d'item. Si l'item correspond à une ligne d'une ListView affichant des noms d'étudiants, le nom du fichier sera “item_student_name”.

Ainsi nommés, il sera facile de rechercher le layout d'une activité ou autre.

1) Le nom des packages ne doit pas contenir d'underscore (_) ni de majuscule !

2) Le nom des packages ne doit pas commencer par com.android. En effet, cette appellation est réservée aux applications créées par Google pour Android.

3) Le nom du package par défaut est décomposé en 3 parties :

• l'abréviation du pays : fr (France), uk (Angleterre), ca (Canada), com (International -> le plus souvent utilisé) ;
• la société qui développe l'application ;
• le nom de l'application.

Exemple : “com.android.sms” représente une application nommée “sms”, créée par la société “Android” à destination internationale (com).

1) Interdiction d'initialiser les variables membres en dehors de leur classe.

2) Les variables de classe doivent être définies de préférence au début du fichier. Si elles ne peuvent pas y être pour une quelconque raison, elles doivent être déclarées avant la fonction les utilisant.

3) Les variables de boucle doivent être déclarées directement dans la boucle :

for (int i = 0; i < size; i++)

et non :

int i;
for (i = 0; i < size; i++)

4) Ne pas réutiliser une même variable dans un même scope pour représenter plusieurs choses différentes (même si elles se ressemblent).

Exemple à ne pas suivre :

Date date = reservation.getStartDate(); 
if (newDate.before(date)) {
	reservation.setStartDate(newDate);
	// ... 2 ou 3 lignes de codes ici
} 
// ... 2 ou 3 lignes de codes ici 
date = reservation.getEndDate();
if( newDate.after(date) {
	reservation.setEndDate(newDate );
	// ... 2 ou 3 lignes ici
}
/*
On peut facilement ajouter ici du code qui manipule date, en pensant que c'est la date de début, si on ne regarde pas tout le code de la méthode. De plus, si le code est repris par un autre développeur, il comprendra difficilement à quoi sert la variable. */

1) Utiliser au maximum les exceptions JAVA existantes (ArithmeticException par exemple, lorsqu'un calcul ne peut être fait parce qu'un opérande est invalide), et ne jamais faire de throw new Exception(“...”), mais faire sa propre classe d'exceptions.  

2) Pensez à centraliser vos exceptions si vous voulez les gérer. Pour cela, créer une classe ExceptionManager permettant de réaliser les tâches à faire lors d'une remontée d'exception (Log, affichage de dialogue, etc ..). Cette opération peut s'avérer difficile par type d'exception, une interface ou un paramètre vous seront peut-être utiles pour différencier de quel Use Case l'exception a été remontée.

1) Ne jamais appeler de méthode marquée deprecated : une méthode marquée deprecated est toujours accompagnée d'un commentaire indiquant quelle autre méthode appeler à la place. Toujours dans le scope de votre API minimum, essayer au possible d'utiliser les nouvelles fonctionnalités en fonction de l'API installé sur votre device.

Exemple :

if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.GINGERBREAD) {
	// only for gingerbread and newer versions
}

Vous pouvez également passer par un boolean depuis les ressources pour savoir sur quel API vous êtes.

2) Utiliser les annotations Android plutôt que de laisser des warnings. Typiquement, pour les utilisations de méthodes ou d'objets disponible dans une version ultérieure de la cible, encadrer par le #1, et rajouter l'annotation @TargetApi(XX).

1) Tous les documents ayant une licence doivent commencer par un commentaire contenant la définition du copyright. Chaque bloc doit être séparé par un espace. Par exemple, si l'on veut contribuer aux sources Android, on écrira :

/*
* Copyright (C) 2013 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* 	http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

2) Avant chaque interface ou chaque classe, une description de celles-ci doit être écrite en commentaire. Le commentaire doit être “JavaDoc” (commencer par /** )

Par exemple:

/**
* Un étudiant correspond à une personne en cours d'apprentissage
*/
public class Student {
}

3) Commenter chaque fonction publique avec la notation de la javadoc:

/**
* 
* @param
* @return
*/

Ceci à pour but de savoir :

- à quoi sert la fonction (1ère ligne) ;

- avec quels paramètres l'appeler (à placer après le @param) ;

- que retourne la fonction (à placer après le @return).

Cette notation permet aussi de générer facilement une documentation du code.

4) Lorsque des parties de code seront implémentées par la suite, laisser un commentaire expliquant ce que doit faire le code manquant précédé de “TODO”. La plupart des IDE gère automatiquement ce genre de tags, dans une TodoList : ceci ajoutant en plus de l'information utile un moyen pratique de suivre ses tâches à faire. Pour l'utiliser efficacement, ne pas oublier de supprimer les “TODO” générés automatiquement par les IDE, pour ne pas se retrouver avec X vrais “TODO” et Y bruits “// TODO auto-generated method stub”.

5) De la même façon que pour le tag TODO, le tag FIXME peut être utilisé pour marquer un commentaire qui indique qu'on sait qu'un code pose problème dans certains cas, mais qu'on n'a pas forcément le temps de traiter dans l'immédiat.

6) Pensez à marquer deprecated les méthodes que vous avez besoin de modifier de façon importante, en indiquant en commentaire de déprécation la méthode de remplacement. Corollaire : dans un code réutilisé (une bibliothèque par exemple), ne jamais modifier les paramètres d'une méthode ; en créer une nouvelle, que l'ancienne appelle, et rendre deprecated l'ancienne éventuellement : si les paramètres ajoutés ne peuvent avoir de valeur par défaut facilement déterminable, laisser les 2 codes. Les IDE modernes permettent de visualiser les appels de méthodes marquées deprecated de manière globale afin d'aider le développeur à intégrer une nouvelle version d'une bibliothèque. Ceci est applicable également aux classes.

1) Pensez à structurer vos fichiers xml en créant des blocs par activité à l'aide des commentaires. Par exemple, l'ensemble des chaînes de caractère de l'activité d'authentification seront précédé d'un commentaire simple en xml m'indiquant que ces chaînes de caractères sont utilisées dans cette activité :

<!-- AUTHENTICATION ACTIVITY --> 
<string name="hello">Hello</string>
				

1) Au niveau du formatage automatique dans les IDE, Google met à disposition des fichiers ici : https://android.googlesource.com/platform/development/+/master/ide.

2) Déclaration d'une variable à la fois.

3) Déclarer les variables types tableau selon cette convention :

int[] array; 

et non

int array[]; 

qui est elle sujette à confusion et tromperie.

4) Ne pas écrire une fonction sur la même ligne qu'une déclaration.

5) Les accolades suivant une condition doivent être présentes sur la même ligne que la condition, séparées d'un espace.

Exemple :

if ( toto == 1) {
//...
} else {
//...
}

6) Une ligne doit faire au maximum 100 caractères.

7) Aérer le code. Ne pas hésiter à ajouter un espace après et avant chaque opérateur.

Ce code :

1 + 2 * 3 / 4

est plus lisible et agréable à lire que :

1+2*3/4

Surtout si nous remplaçons les chiffres par des noms de variables.

De même, sauter des lignes entre des blocs de code ou des suites d'instructions pour rendre le code moins compact et plus lisible, ainsi que faire ressortir des suites d'instructions liées.

1) Ajouter un retour à la ligne après chaque paramètre d'un widget. Par exemple, cette déclaration :

<ImageView
android:id="@+id/iv_back"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentLeft="true"
android:layout_alignParentTop="true"
android:layout_centerVertical="true"
android:layout_marginLeft="@dimen/marginLeft"
android:layout_marginRight="@dimen/marginRight"
android:contentDescription="@string/app_name"
android:src="@drawable/ico_back" />

et plus lisible que :

<ImageView android:id="@+id/iv_back" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentLeft="true" android:layout_alignParentTop="true" android:layout_centerVertical="true" android:layout_marginLeft="@dimen/marginLeft" android:layout_marginRight="@dimen/marginRight" android:contentDescription="@string/app_name" android:src="@drawable/ico_back" />

Comme vu dans la section XML, nous devons rendre les plus lisibles possibles les fichiers de ressources. Il s'avère que souvent nos composants ont x paramètres. Les styles sont là justement pour permettre au développeur de pouvoir factoriser le code des ressources et ainsi rendre plus lisibles et plus simples les changements à opérer sur le graphique.

Pour cela, vous devrez créer un style par composant graphique pour votre application. Ces styles pourront être personnalisés par types de charte graphique que vous pourrez trouver dans votre application.

Utilisez les thèmes pour personnaliser les composants par défaut d'Android (Listes, Dialogs,...).

Par exemple, si nous avons un composant Button, nous pourrons trouver comme style :

• Button Action ;
• Button NetWork ;
• etc.