The Power of Proper Planning and Practices/fr

│ English (en) │ français (fr) │ português (pt) │

Plan for cross-platform up front

Il y a plusieurs avantages à développer en prévoyant d'être cross-platform. Probablement le plus grand avantage est que vous pouvez une meilleur résultat et un logiciel bien plus fiable. Cela est d^au fait que le développement cross-plattform requiert que vous passiez plus de temps à planifier votre logiciel avant de commencer à écrire le code. Cela vous force aussi à développer de bonnes habitudes de programmation, à tester de manière plus approfondie votre logiciel, et de développer une approche plus disciplinée envers ce que vous faites. Ces choses (planification, tests, discipline) tendent à déborder sur certains aspects de vottre développement, résultant en des améliorations encore meilleures dans le design et la fiabilité.

Un autre avantage du développement cross-platform est le fait qu'il vous expose aux autres plateformes. Par exemple, de nombreux développeurs Windows et probablement tous les développeurs Linux devraient bénéficier du temps passé simplement à utiliser un Mac de manière à développer une appréciation pour la facilité d'utilisation des logiciels et l'esthétique. Et de nombreux développeurs Windows pourraient bénéficier de voir comment Linux tend à utiliser les fichiers textes et les scripts pour beaucoup de choses, sans perte de performances des applications.

Un troisième avantage du développement cross-platform est qu'il est par définition inclusif, ce qui vous force à prendre plus en considération vos utilisateurs que le font la plupart des programmeurs mono-plateforme.

La meilleure façon de faire une application cross-platform est de la concevoir pour être cross-platform. Si vous prévoyez d'ajouter un support cross-platform plus tard à votre application terminée, vous pourriez trouver que vous avez à réécrire certaines portions ou pire, découvrir que vous êtes dans un cul-de-sac Windowsiens qui fait que l'ajout du support cross-platform est difficile ovoire impossible.

Si vous avez déjà développé une application Windows pour Delphi, il est possible dans certains cas de la convertir en application cross-platform sans avoir à tout reprendre. Si vous voulez réaliser une conversion à sens unique de votre code et fiches Delphi vers Lazarus, vous pouvez utiliser quelques commandes de conversion du menu Outilsde Lazarus. Vous pouvez également convertir votre application Delphi vers Lazarus, mais prenez en compte la compatibilité avec Delphi [discussion needed].

Separate code into UI and non-UI units

//Séparez le code en Unités UI et non-UI (Interface Utilisateur)//

C'est probablement l'une des pratiques de programmation les plus importantes et que vous pouvez utiliser avec n'importe quelle application, que ce soit entre plates-formes ou non. Elle consiste à diviser votre code en unités d'interface utilisateur (UI - User Interface) et unités d'interface non-utilisateur (non - UI). En général, cela signifie que vos unités "non UI" ne doivent pas implémenter une interface utilisateur du programme et que vos unités d'interface utilisateur ne contiennent aucune des parties de calcul ou de base de données du programme. Dans la pratique, une bonne façon d'appliquer cette séparation consiste à exiger que les unités que vous développez utilisent uniquement des unités appropriées à chacune des parties de cette «division». Par exemple, vos unités non-UI ne doivent pas utiliser d'unités LCL telles que les formulaires, les boîtes de dialogue, les StdCtrls (contrôles standards), les boutons, les graphiques, les contrôles, les "LMessages", etc., ou l'une de vos unités qui utilisent ces unités. Et vos unités UI ne devraient probablement pas utiliser des unités telles que Math, Dbf, MySQLDB4, etc. Suivez l'exemple des unités Free Pascal et Lazarus elles-mêmes, où les unités à usage général comme "SysUtils", Classes et Variantes n'utilisent pas d'unités LCL Et les unités LCL comme "Forms" et "Controls" ne fournissent pas de routines générales.

Il existe plusieurs avantages à diviser votre code de cette manière. Par exemple, cela signifie que vous pourrez utiliser vos unités "non-UI" dans n'importe quel type de programme, que ce soit une application GUI, une bibliothèque, une application console, même une application Web, sans apporter de modifications au code. Et cela signifie également que, si nécessaire, vous pouvez développer une interface utilisateur complètement différente pour votre programme ou passer à une autre bibliothèque ou contrôle "UI" sans modifier le code sous-jacent "non-UI". Il est également essentiel que ce partitionnement soit effectué dans de grands projets afin que plusieurs développeurs puissent travailler sur différentes parties du programme sans se gêner les uns des autres.

Vous pouvez également trouver utile de subdiviser davantage votre code "non-UI". Par exemple, vous voudrez peut-être mettre tout le code d'accès à la base de données dans un ensemble d'unités et toutes les logiques métier et code de cryptage dans un autre ensemble d'unités. De plus, vous voudrez mettre tout le code dépendant de la plate-forme (shelling, registre, presse-papiers, etc.) dans son propre ensemble d'unités pour isoler ce code et faciliter le portage sur d'autres plates-formes.

Use batch files and shell files

Even though Lazarus allows you to edit and compile code and set most compiler switches without ever leaving the IDE, you'll probably find it useful to create several batch files for each project. Batch files are just special text files containing console commands; you create them with a text editor. With Windows, batch files have a .bat or .cmd extension; with OS X and Linux, batch files have an .sh extension. You typically run a batch file by entering its name in a console window, as follows:

With Windows:

 mybatch.bat

Note that you can omit the .bat extension if there's no .exe file with the same name.

With Unix:

 ./mybatch.sh

There are many way that batch files can be used in development. For example, you might have one set of compiler options that you use during development and another set that you use to create the executable that you distribute. Here's an example of a command you can put in a batch file that runs the Free Pascal compiler:

With Windows:

 c:\lazarus\pp\bin\i386-win32\fpc.exe -Sda -Cirot -gl %1

With Unix:

 /usr/local/bin/fpc -Sda -Cirot -gl $@

The above command compiles the unit or non-GUI program specified on the command line with Delphi compatibility, assertions, I/O checking, range checking, overflow checking, stack checking, and line number tracing turned on. Note that you can add additional pre- and post-compile commands to a batch file. For example, you could run the strip.exe utility to shrink the size of your executable or copy the executable to a different folder for testing.

Here's a similar command that you can put in a batch file to compile a GUI program that you specify on the command line:

With Windows (all on one line):

 c:\lazarus\pp\bin\i386-win32\fpc.exe -dLCL -WG -Sda -Cirot -gl
  -Fuc:\lazarus\lcl\units\i386-win32;c:\lazarus\lcl\units\i386-win32\win32 %1

With OS X (all on one line):

 /usr/local/bin/fpc -dLCL -WG -Sda -Cirot -gl -Fu/usr/local/share/lazarus/lcl/units/powerpc-darwin
  -Fu/usr/local/share/lazarus/lcl/units/powerpc-darwin/gtk -Fl/usr/X11R6/lib/ -Fl/sw/lib/ $@

How to avoid using a debugger

Using a debugger is rarely much fun. It often means that you've given up trying to figure out what's wrong with your program and have turned to the debugger as a last resort. Here are some simple techniques that you can employ that will help minimize your use of a debugger:

• Develop with all run-time checks turned on. You can turn off some or all checks when you create an executable for distribution, although the code-size and performance improvements of turning checks off are pretty negligible. Plus, leaving checks turned on can help you locate bugs that turn up later.

• Use assertions. Like run-time checks, assertions can be turned off later, although leaving them on can help you diagnose bugs that your users encounter.
• Compile with line number tracing turned on. You can turn this off when you release your program to shrink the size of the executable.
• If your code handles exceptions, you can still determine the line number and source file name of where the exception occurred using line number tracing and the FPC BackTraceStrFunc function, as in this example code:

   try
     raise Exception.Create('Exception here');  
   except
 // Handle exception here.
 {$IFDEF FPC}
     WriteLn(BackTraceStrFunc(ExceptAddr));
 {$ENDIF}
     end;

The {$IFDEF} and {$ENDIF} lines ensure that you can compile this code with Delphi too.

• Initialize variables. Although both Delphi and FPC initialize global variables and object fields, variables local to routines are not initialized. It's a good idea to initialize all variables just to be clear about what their initial values are.
• Turn on compiler warnings and pay attention to them.
• Use "with" sparingly. Although the Pascal with statement can save you a lot of typing, it can also hide incorrect field references if you use nested with statements or if a field with the same name as a field in your with's target is added someday to an ancestor class.
• Run your code through multiple compilers. There will always be differences in how different compilers process your code. Sometimes these differences are dictated by the underlying operating system or hardware. Try to compile your program (or at least the non-UI units) with two or three compilers. For example, if your code compiles and runs correctly with Delphi and on at least two of FPC's platforms, you'll be that much closer not only to a stable cross-platform app but also to having a program that you know will work.