Quelques conseils pour faire un bon logiciel

Vérifiez que votre application est « propre ». Il doit y avoir autant de mémoire libre avant l'exécution de votre application qu'après, ce qui signifie que vous devez libérer correctement toute ressource allouée. Même si certaines implémentations disposent d'un programme récupérateur de mémoire, il est toujours bon de libérer la mémoire qu'on a utilisée, d'abord, pour que votre programme soit portable et ensuite par habitude, car le jour où vous programmerez, dépourvu d'un programme récupérateur de mémoire, vous pourriez avoir des surprises.

Tout d'abord, évitez les messages de confirmation inutiles, par exemple, les « Voulez-vous vraiment quitter ? » qui n'ont aucun intérêt, si ce n'est énerver l'utilisateur. Ne classons pas hâtivement dans ce type de message les confirmations d'annulation d'opération, surtout si celles-ci sont longues. Un message du type : « Un téléchargement est en cours, voulez-vous vraiment quitter ? » peut dans ce cas s'avérer très utile. N'oublions pas non plus le « Voulez-vous enregistrer les modifications apportées à votre document » : l'absence de cette boîte de dialogue pourrait se révéler très désagréable pour l'utilisateur malchanceux qui quitterait le programme, sans le sauvegarder ; bien sûr, dans ce cas, ne demandez pas la sauvegarde si aucune modification n'a été apportée au nouveau document, ce qui est très agaçant.
Voyez également FAQ : Comment avertir l'utilisateur ? pour savoir comment faire des boîtes de dialogue de confirmation.

Veillez également à centrer vos fenêtres sur l'écran. En effet, lors de la conception avec Borland C++Builder (c'est valable pour Delphi également), la position de la fenêtre est définie grâce aux propriétés Top et Left de celle-ci. Donc sur votre superbe écran 17 pouces qui a une résolution de 1024 par 768 pixels, la fenêtre sera - à peu près - centrée, mais le malheureux qui n'a qu'un écran 15 pouces verra la fenêtre beaucoup trop en bas à droite. Cela peut être effectué de deux manières : les fiches (classe TForm) ont la propriété Position que vous pouvez positionner à poScreenCenter. L'autre méthode, presque aussi simple est la suivante, placez tout simplement le code suivant dans le constructeur de votre fiche :

Left = Screen->Width/2 - Width/2;
Top = Screen->Height/2 - Height/2;

Ce code se comprend aisément : Screen->Width donne la largeur de l'écran en pixels, Screen->Height la hauteur. Donc si la résolution de votre écran est de 1024 par 768, Screen->Width sera égal à 1024 et Screen->Height à 768.

Dans ce registre, évitez également de faire des fenêtres trop grandes, car avec votre résolution, le résultat est parfait, mais avec la résolution inférieure, une partie de la fenêtre peut dépasser de l'écran. Adaptez donc vos fenêtres à la résolution de l'écran.

Vous pouvez consulter Comment obtenir la résolution de l'écran ?

C'est ce que nos amis anglophones appellent « an idiot-proof application ». Cela signifie que votre application ne doit pas présenter le risque potentiel qu'une mauvaise manipulation cause la perte de données ou plante totalement le système. Ne laissez rien au hasard. Par exemple, pendant une opération de listage d'un répertoire, désactivez les boutons qui pourraient planter l'application, comme celui qui supprimerait ce répertoire :

Button1->Enabled = false;

Pendant de longues opérations, il ne faut pas que votre logiciel se bloque. L'utilisateur pourrait être content, pendant ce temps-là, de consulter l'aide du logiciel, par exemple. Or, pour cela, il faut que votre application récupère les messages que Windows lui envoie. Vous avez deux solutions : où vous faites périodiquement un appel à la méthode ProcessMessages de l'objet Application, ce qui a le mérite d'être assez simple :

while(/* Condition */)
{
//...

//...
Application->ProcessMessages();
}

Un long traitement étant dans la majorité des cas une boucle, cela reste très simple à mettre en œuvre. L'autre solution est l'utilisation des Threads, moins simples à mettre en œuvre, mais plus puissants. En effet, vous pouvez régler la priorité de celui-ci. En fait, rajouter un Thread permet de lancer une opération parallèlement à l'exécution normale du processus. Le schéma suivant illustre ce fait (nous considérons pour simplifier que l'application utilise 100% du temps processeur) :

Le but de ce document n'est pas d'expliquer la mise en œuvre technique des threads, mais de signaler leur existence. Sachez simplement que pour créer un nouveau thread, il suffit de cliquer sur Fichier/Nouveau…/Thread. L'aide explique bien l'utilisation de ceux-ci.

Dans C++Builder, chaque composant possède une propriété Hint, qui permet de définir une bulle d'aide. Il faut attacher une grande attention à la rédaction de ces bulles d'aide qui seront la première aide de l'utilisateur. Lorsque vous cherchez un composant dans l'IDE, ne vous aidez-vous pas de ces bulles ? Ne surchargez pas ces bulles ; faites-les concises telles « Nouveau document » plutôt que « Créer un nouveau document ». N'oubliez pas que pour qu'elles apparaissent, le composant doit avoir sa propriété ShowHint à true. Positionnez la propriété ShowHint de la fiche à true et tous les composants de la fiche verront cette propriété passer à true.

Un splash screen est un écran montré au démarrage de votre programme, présentant généralement son logo. Lorsque vous démarrez Borland C++Builder, Word, KDevelop… vous pouvez en avoir un exemple. Placer un splash screen au chargement de votre logiciel peut être une très bonne idée, et une belle image peut donner envie à l'utilisateur d'utiliser votre logiciel (sauf si celui-ci est mal conçu, bien sûr). Cependant, si votre logiciel se charge instantanément, inutile d'y rajouter un splash screen qui resterait affiché durant 5 secondes, ce serait du temps perdu. Que diriez-vous si à chaque fois que vous ouvrez Notepad, vous devez attendre quelques secondes. 2 Évitez également les écrans de présentation « flash-ouillant », fluo, qui font vraiment toc.

Consultez également Comment faire un splash screen pour son application ?.

Cette remarque est très subjective, mais pour ma part, je pense qu'il vaut mieux rester sobre, donc éviter par exemple les skins. Bien que permettant une personnalisation de l'application, elles gênent la lecture et ne sont pas claires : avez-vous déjà essayé de chercher le bouton d'options de Winamp ? De plus, ces skins ralentissent le programme. Laissez également les couleurs systèmes (surtout pas de fond tout noir, comme c'est la mode sur Internet), cela fait partie du souci d'adaptation à l'utilisateur : c'est lui qui choisit les couleurs de ses programmes et non vous qui devez lui imposer. De plus, ce qui fait la « beauté » d'un OS, c'est son unité, donc avoir des fenêtres de toutes les couleurs, les unes avec des skins, les autres sans, est vraiment horrible.

Veillez à ce que votre logiciel soit cohérent visuellement. Il faut que toutes vos boîtes de dialogue aient la même apparence, le même en-tête. Si vous faites une barre d'outils, utilisez les mêmes tons pour les images. Un bon exemple est le forum de Developpez.com.

Pour distribuer votre application, ce qui se fera très probablement par Internet, veillez tout d'abord à compresser votre programme. Soit en faisant une archive Zip toute simple, soit en utilisant un outil de déploiement comme InstallShield, InnoSetup ou GhostInstaller, ce dernier permettant l'obtention d'un fichier plus petit qu'un fichier Zip, grâce à la compression CAB (Microsoft CABinet). Cependant, évitez de grossir votre application en lui associant un programme d'installation, surtout si celle-ci ne nécessite aucun fichier supplémentaire par rapport à l'exécutable. Dans ces cas-là, préférez une archive Zip toute simple.

Rien de pire qu'un logiciel non documenté, ou mal documenté. Bien sûr, l'aide à fournir dépend du programme et de sa taille. Pour créer l'aide, vous pouvez télécharger gratuitement Microsoft HTML Help Workshop. Ce programme permet de faire des fichiers d'aide HTML ; pour faire les anciens fichiers d'aide, utilisez Microsoft Help Workshop disponible dans le répertoire Help\Tools de votre répertoire principal C++Builder. Fournissez au moins un fichier Lisez-moi.txt (ou Readme) ; évitez les fichiers .doc, tout le monde n'a pas Word ; dans ce cas, préférez le format RTF, reconnu par tous les traitements de texte. Mais un fichier .txt est toujours mieux adapté, car il est très rapide à s'ouvrir et peut être consulté en un clin d'œil. Ce fichier est important, il présente votre application ; il devrait contenir au moins les rubriques suivantes : informations sur le logiciel (nom, auteur, site, etc.), but du logiciel (brève description ; évitez « Le meilleur logiciel de tous les temps »), la licence, la configuration requise, la procédure d'installation (si elle est compliquée) et enfin, vous pouvez y placer les évolutions du logiciel.

Vous trouverez dans la section Delphi deux documents :

• Créez vos fichiers d'aide HTML pour vos applications Delphi 6 par Stéphane Vaillant
• Créez un fichier d'aide HLP pour Delphi par feelweb.