Contributions > 60 - AtoutFox > 50 - VFP9 Francophone > 5.1 - Traductions

# 0000000217
ajouté le 28/06/2005 10:49:14 et modifié le 28/06/2005
consulté 15643 fois
Niveau débutant

Version(s) Foxpro :
VFP 9.0
VFP 8.0
VFP 7.0
VFP 6.0
VFP 5.0
VFP 3.0

Traduction libre d'un article vu sur http://www.universalthread.com/VisualFoxPro/DoDont.asp

[J'ai supprimé les points sujets à controverse, dupliqués ou spécifiques au forum UT. J'ai maintenu les noms des auteurs dans la version anglaise]

Do's and Don'ts (A faire et à éviter)

Hi All [from John Koziol]:

Bonjour [de John Koziol]:

• Don't use PUBLIC variables. They're hard to track down and not good design. Use object methods. This is Jim's mantra and a good one.

N'utilisez aucune variable publique; elles sont difficiles à retrouver et d'une conception médiocre. Utilisez des méthodes objet à la place (auteur Jim Mantra)

• Don't use Formsets. Formsets suck. Formsets are the black holes of VFP objects; hard to manage and impossible to escape once you've used them.

N'utilisez pas de groupe de formulaires. Ce sont les trous noirs des objets VFP ; difficiles à gérer et impossible de s'en débarrasser après coup.

• Don't overload your Form.Refresh. Too much logic in Form.Refresh slows down an app considerably. Especially try to avoid requerying or SCAN type ops in Refresh.

Ecrivez peu de code dans la méthode Refresh() du formulaire. Trop de code ralentit l'application considérablement. En particulier évitez les Requery() et les SCAN.

• Use type and object prefixes! It's not that hard to get in the habit of and it makes your code a helluva lot readable.

Utilisez des préfixes de type et d'objet (conventions de nomination VFP). C'est une habitude facile à prendre et votre code est bien plus lisible.

• Forget SET FILTER. SET FILTER can slow down your app much worse than a parameterized view.

Oubliez SET FILTER qui beaucoup plus lent qu'une vue paramétrée

• Don't forget your SETs. Remember to set your SETS in the BeforeOpenTables or Load event of a DataEnvironment when a form uses a Private Datasession.

N'oubliez pas vos SETs ; placez les dans la méthode BeforeOpenTables() ou Load () et utilisez une session de données privée

• Parameterized views require parameters! If the parameter is a Form property, then the view will error on opening unless you've set NoDataOnLoad for the cursor to .T. You can requery in Form.Init to get the proper rows.

Les vues paramétrées nécessitent des paramètres ! Si le paramètre est une propriété du formulaire, vous aurez une erreur à l'ouverture de la vue sauf si son NoDataOnLoad est .T. Vous pouvez rafraîchir la vue dans l'Init() du formulaire pour charger les enregistrements souhaités.

• All tables should have primary keys! All of them. No exceptions to this rule. None. Ever. For any reason.

Toute table doit avoir une clé primaire ! Aucune exception à cette règle, jamais, aucune raison ne peut la justifier.

• Avoid code repetition. If Apply and OK buttons both contain save code, then they should call a common method to save.

évitez la duplication du code. Par exemple, si vous boutons OK et Appliquer nécesssitent le même code, ils doivent appeler un méthode commune.

• Consistency! Think long and hard about right-click and dbl-click behaviors for controls. Be prepared to explain why clicks act differently for different instances of the same control type. DOCUMENT those differences with ToolTips.

Cohérence ! Pensez attentivement au comportement du clic droit et du double clis sur vos contrôles. Préparez-vous à expliquer pourquoi le clic agit différemment dans plusieurs instances d'un même contrôle. DOCUMENTEZ ces différences avec une bulle d'aide.

• The default Windows Close button. For Pete's sake, use it! If a Form can be closed then enable the Close button. A lot of people make Closable = .F. yet put a Close or Quit button on a Form. Why??

Utilisez le bouton de fermeture du formulaire par défaut ! Si un formulaire peut être fermé, autorisez ce bouton. Nombreux sont les développeurs qui règlent Closable à .F. avec un bouton de fermeture sur le formulaire. Pourquoi ??

• For any full size app (little utilities etc. don't count) do NOT use the VFP base classes directly on your forms and form classes. Instead, subclass them all (and leave them default if you wish) and use those instead.

Quelle que soit la taille de votre application, n'utilisez jamais les classes de base directement. Utilisez toujours vos propres sous-classes.

• Do not use underscores in variable and field names. It's hard to remember where you used them and where you didn't. -- Peter Robinson (Or at least be consistent about it) Yeah (to consistency), but I find in practice that it is a whole lot easier to consistently leave them out then to consistently put them in. PR

N'utilisez pas de tiret bas dans vos noms de variables et de champs. Il est trop difficile de se souvenir quand et où vous les avez utilisés. Au minimum soyez consistant dans leur usage.

• If you're doing general business development, do yourself a huge favour and buy (or at least evaluate) a commercial framework. Most come with full source code, giving you a look at the techniques used by some of the best developers in the business. -- Al Doman

Si vous développez des applications pour les entreprises, faites vous en cadeau en achetant, ou au minimum en évaluant un chassis applicatif. La plupart fournissent le code source complet, vous pouvez ainsi apprendre à la lecture du code écrit par les meilleurs développeurs du métier.

• Where possible, follow MS Windows Design Guide standards. It's what users expect in application look-and-feel. Also look at Alan Cooper's book, "About Face" for great information about what makes a successful GUI.

Autant que possible, suivez le guide de conception Microsoft pour l'interface utilisateur.

• comment, Comment, COMMENT! Don't assume that you're the only one who'll ever need to read and understand your code. Giving meaningful names to Procedures, Properties and Variables also helps here. -- Larry Moody

  Not only Comments in code, but comments for properties and methods in the form and class designer, tables and fields in the table designer, and modules in the project manager. -MHelland

  And you will find soon that your comments are very useful for you... -- VladGrynchyshyn

Commentez votre code, vos propriétés et méthodes, non seulement pour les autres mais pour vous même.

• Try to avoid multiple return statements, if, of course, it doesn't lead to much complexity. - Nadya Nosonovsky

évitez les RETURN multiples au sein d'une procédure, fonction ou méthode.

• If you want to perform exact match in your seek function, use SEEK PADR(field_name,field_len). - Nadya Nosonovsky

Si vous voulez une correspondance exacte dans un SEEK sur un champ caractère, utilisez SEEK PADR(field_name,field_len)

• Use local tables when possible

Utilisez des tables locales autant que possible

• When subclassing or making base classes, do NOT change properties that cause automatic resizing of control. For example, do NOT set AutpSize property of the checkbox - you will find that you cannot get rid of it even when you set it to .F. on the form. Do NOT set Integral Height of listbox. Its strange, but do NOT make a label class with right or centered alignment - you will find that labels moves around without any reason. -- VladGrynchyshyn

Dans vos sous-classes ne changez aucune propriété qui cause le redimensionnement automatique du contrôle : Autosize, IntegralHeight, etc. Vous ne pourrez plus vous en débarrasser.

• Use ActiveX controls, specially such as TreeView, ImageList, TabStrip. They enhance application interface a lot with little cost, and sometimes even help to solve some problems. -- VladGrynchyshyn

Utilisez les contrôles ActiveX comme TreeView, ImageList, TabStrip. Ils améliorent votre interface utilisateur et peuvent vous aider à résoudre des problèmes.

• Never allow a user to modify a PK; use a surrogate key instead. Also, avoid using compound expressions for PK's; slows performance and hard to maintain.

N'autorisez jamais l'utilisateur à modifier la clé primaire d'une table ; utilisez des clés abstraites (subrogées). Evitez les clés primaires composites : elles ralentissent l'application et sont difficiles à maintenir.