Principes de conception

De LXDE.org
Aller à : navigation, rechercher
  • Si seulement une partie des API contenues dans une bibliothèque est nécessaire, essayer de les extraire et de les inclure dans son programme chaque fois que cela est possible (attention aux licences).
  • Utiliser une bibliothèque d'un autre gestionnaire de bureau uniquement si elle est petite, très efficace et qu'elle engendre peu de dépendances.
  • Utiliser un démon seulement s'il est nécessaire pour de bonnes raisons.
  • Chaque fois que c'est possible, on doit pouvoir modifier de façon graphique les options de base.
  • Conserver une interface simple et intuitive. Ne pas faire de look trop typé geek.
  • Observer les conventions ade GNOME et de Microsoft Windows (MS Windows) et essayer de suivre les habitudes du plus grand nombre d'utilisateurs. Ne pas faire d'interfaces différentes de MS Windows juste pour se différencier. L'habitude des utilisateurs doit être prise en compte. La facilité d'utilisation doit toujours être la pincipale préoccupation. MS Windows n'est peut-être pas le plus efficace sur certains points mais la plupart des gens y sont habitués. Combattre la volonté des utilisateurs n'est pas la meilleure solution.
  • Essayer de raccourcir le temps de démarrage au maximum pour un plus grand confort d'utilisation.
  • Essayer de conserver au maximum la compatibilité avec les anciennes versions de GTK+ (la version 2.6 est conseillée). Tenter de rendre les fonctionnalités compatibles avec des versions plus évoluées de GTK+ optionnelles avec leurs propres conditions de compilation et des macros de compatibilité. La version de GTK+ utilisée peut être intégrée dans votre programme en C comme suit :
#if GTK_CHECK_VERSION( 2, 10, 0 )
    /* écrivez vos trucs spécifiques pour GTK+ 2.10+ */
#endif

Styles de codage

Actuellement, le style de codage de tous les programmes de LXDE sont différents. Cependant, il est bon pour un projet d'avoir un style de codage cohérent entre tous les programmes. Le style de codage peut être le suivant :

#include "un-header.h"
void function()
{
 if( valeur )
 {
   char str[10];
   for( i = 0; i < 10; ++i )
   {
     faire_qqch();
     str[i] = '0' + i;
   }
   str[i] = '\0';
 }
 else if( valeur2 )
 {
   faire_d'autres_choses( param1, param2, param3 );
 }
 else
 {
   ne_rien_faire();
 }
}
  1. Utiliser des indentations de quatre espaces au lieu de tabulations.
  2. Ne pas mettre d'accolade ouvrante en fin de ligne mais la mettre sur une ligne séparée.
  3. Ne pas indenter les accolades.
  4. Des mots différents dans un nom de fichier devraient être séparés par un trait d'union (utiliser, par exemple, « fenêtre-principale.c » plutôt que « fenêtreprincipale.c »).
  5. Ajouter des espaces entre les opérateurs et leurs opérandes.
  6. Ne pas mettre d'espace entre le nom d'une fonction et ses parenthèses.
  7. Ajouter des espaces entre la liste des paramètres d'une fonction et les parenthèses qui les entourent.

Certaines règles ne sont quand même pas suivies. Si quelqu'un trouve ces règles agaçantes, le projet est ouvert à la discussion. De toute façon, on peut utiliser des outils de formatage comme un style pour reformater tout le code source.