6) Oublier de sauvegarder ou compiler
Certains environnements récents font automatiquement la sauvegarde de votre projet avant la compilation. Il peut cependant arriver des erreurs lors de l'utilisation de vieilles versions de fichiers .class.
Ainsi, si l'une de vos classes dépend d'une autre, et que vous compilez cette classe pour la première fois, le fichier sera compilé avec le nom correct en .java s'il ne trouve pas le fichier .class correspondant. Cependant, si vous éditez les deux fichiers en même temps, le fait de recompiler l'un des deux ne recompilera pas forcément l'autre.
L'une des solutions possibles est simplement de compiler tous les fichiers Java d'un dossier après chaque itération. Une autre méthode plus élégante serait d'écrire un fichier make de telle sorte que seuls les fichiers trop vieux soient compilés.
Le problème se complique pour les applets Java, étant donné que l'on passe par le chargeur de classe du navigateur. Si vous recompilez l'applet et ne faites que recharger la page, la classe en mémoire sera utilisée: il faut redémarrer le navigateur pour pouvoir prendre en compte la nouvelle classe.

7) Priorité de opérateurs
Lors d'instructions longues, on peut oublier les régles de priorité qui régissent Java. Ainsi, il faut se souvenir que les opérateurs sont évalué de gauche à droite dans l'ordre de priorité suivant (du plus prioritaire au moins):

8) Ne pas réinventer la roue
Si le fait de travailler avec l'orientation Objet à l'esprit permet de construire un programme composé de plusieurs petites "briques" simples, indépendants et réutilisables, il risque aussi de vous faire coder des fonctions qui existent déjà en standard dans Java, soit par le biais de l'API Java, soit dans la bibliothèque de composants de l'entreprise. Bien connaître son environnement est la meilleure manière de ne pas perdre de temps en programmation inutile.

9) Gestion des exceptions
Le système de gestion de exceptions de Java est sophistiqué, mais difficile à conceptualiser d'entrée de jeu. Il ne devrait pas poser problème aux programmeurs venant du monde C++, mais ceux venant de C y verront peut-être une source de complications.
Par exemple, oublier de nommer l'exception provoquera une erreur (facilement réparable grâce au message du compilateur):

try
  {
  stream1 = new FileInputStream("donnees.txt");
  }
catch (IOException)
  {
  message("Impossible d'ouvrir data.txt");
  }

Il aurait fallu simplement ajouter "ie" : catch (IOException ie) { ... } .

L'ordre d'écriture de clauses catch dans un bloc try-catch défini un ordre de priorité pour les exceptions, mais chacun de ces clauses attrapera toutes les exceptions de la classe déclarée ou de n'importe quelle de ses sous-classes. Oublier cela peut amener à avoir des clauses qui ne sont jamais atteintes, ce que le compilateur Java traite comme étant une erreur sérieuse.

try
  {
  serviceSocket.setSoTimeout(1000);
  newsock = serviceSocket.accept();
  }
catch (IOException ie)
  {
  message("Erreur de connexion");
  }
catch (SocketException se)
  {
  message("Erreur de time-out");
  }

SocketException étant une sous-classe de IOException, le bon code serait:

try
  {
  serviceSocket.setSoTimeout(1000);
  newsock = serviceSocket.accept();
  }
catch (SocketException se)
  {
  message("Erreur de time-out");
  }
catch (IOException ie)
  {
  message("Erreur de connexion");
  }

10) Ne pas tester son code
Tous comme le fait de mettre des commentaires, tester son application peut sembler à certain être la démonstration d'un manque de confiance en ses capacités. Il n'en est évidemment rien: tester est bien au contraire la démonstration d'un désir de bien faire.
Plus généralement, il est de bon ton de glisser des tests au sein de son code: gestion des erreurs, des plantages du programme ou de la machine, des problèmes avec le système d'exploitation, les erreurs de disque et de fichier, vérification des messages envoyés par l'OS.
De même, faire des tests de performance ne fera que du bien à votre application: un programme ne peut pas toujours blâmer sa lenteur sur la machine sur laquelle il tourne, mais peut-être plutôt à un algorithme qui ralentirait l'ensemble du processus.
Le test devrait faire partie intégrante du processus de création: on ne teste pas à la fin, mais tout le long de l'écriture du code. Tester son code à la fin ne ferait que rendre impossible la possibilité de donner une estimation de date butoir, et ne permet pas de faire la différence entre un gros bug dans une fonction majeure ou un petit oubli dans une sous-fonction anodine.
Le test est le meilleur moyen de garder son code sous contrôle (cela permet de mieux connaître ses classes, par exemple), et permet de faire évoluer le code naturellement.

Tous ces conseils peuvent paraître évidents aux programmeurs chevronnés qui lisent cet article, mais certaines évidences ne sont-elles pas dues au fait que l'on est déjà passé par de telles erreurs ? Personne n'est à l'abri d'un déboguage, et nous espérons que cet article vous permettra d'augmenter encore votre rigueur de programmation.

Page 1 | 2