Nos petits trucs utiles de développeurs

**Droïde Système7** · 19/11/2007, 11h54

Bonjour

J'espère que je poste dans le bon forum, sinon merci à la modération de rediriger ce thread.

Depuis longtemps, j'avais envie de créer quelque chose de très utile pouvant servir à tout le monde et surtout soit au niveau débutant, mais puisse, pourquoi pas, également servir aux autres.

Voici donc un thread entièrement consacré aux petits trucs sans prétention bêtes comme choux, mais très efficaces à l'usage.

Il ne s'agit en aucun cas de code compliqué ni de manipulation de haut vol ; tout le contraire et accessible à tous.

Je vous invite pour notre plus grand plaisir de développeurs d'ajouter vos trucs.

Aller, je commence...

BUT : Comment s'y retrouver dans une feuille de plusieurs milliers de lignes, lorsque l'on réalise des modifs un peu partout éparpillées dans différentes procédures et fonctions ?

C'est une technique que je nomme "Mickeytisation". Pourquoi ? hé bien vous allez tout de suite comprendre.
Imaginez une feuille de 50 000 lignes, vous avez repris le code d'une dizaine de procédures et quelques fonctions, alors ensuite si dans les semaines à venir, vous vous apercevez qu'un comportement anormal de votre appli provient (ou peu provenir) de ces modifications ; là intervient ma Mickeytisation.

Exemple :
En face de chaque bloc modifié, je pose au gré de mon imagination un"riri", ou un "loulou", ou encore un "fifi", etc.
Je complémente par le datage de ces modifs afin de mieux m'y retrouver.
Mais attention, chaque "loulou" par exemple correspondra à une seule série de modification.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
procedure...
begin
...        // loulou   11/2007
end;

A l'aide de la fonction rechercher de votre EDI, c'est ensuite un jeu d'enfant d'aller consulter chaque bloc modifié correspondant à telle ou telle date. La semaine dernière encore, ce truc m'a bien évité des heures et des heures de recherche !
Ne pas oublier en en-tête de chaque feuille d'écrire la correspondance des modifs, style : "loulou" = ajout option impression... du 17/11/2007

Encore un autre truc :

BUT : En plein travail, je dois m'absenter ou bien fermer mon PC, etc., comment retouver rapidement l'endroit exact de ma dernière écriture de code lors de la réouverture de mon EDI ?

Simplement de taper n'importe quel caractère juste à l'endroit que vous étiez avant de passer à autre chose. Suffit en reprenant votre travail de lancer la compil, le compilateur vous indiquera gentiment l'endroit exact en question.

J'espère que ce thread nous sera utile

A vous de jouer et de nous donner vos trucs !

**alainvh** · 19/11/2007, 13h52

Bonjour DS7 (ton pseudo est trop compliqué pour moi

)
Ton idée est intéressante : si ça marche, le problème à terme sera de classer tous les "trucs" afin de s'y retrouver rapidement sans avoir à lire l'intégralité de ton topic.
Je participe donc, au niveau "ras des pâquerettes", mais c'est mon niveau...

En cas de grosses modif, je fais préalablement une copie de mon dossier de projet et je renomme ce nouveau dossier en incrémentant : j'ai ainsi Projet0, Projet1, Projet2, etc... En cas de grosses cata, on peut toujours redémarrer avec le projet précédent.

En cas de petites modif, je copie la procédure à modifier et l'encadre d'accolades { } pour la mettre en remarque : je peux ainsi la récupérer facilement si les nouveautés apportées ont un résultat pire que le précédent...

Cordialement,
Alain

**Droïde Système7** · 19/11/2007, 14h28

Bonjour Alain,

Tu es le premier à encourager ce fil et je t'en remercie.

En effet, ensuite au niveau du classement... mais ici n'oublions pas notre fameuse équipe de la rédac et anciens confrères que je salue amicalement au passage.

Tu me fais penser à donner ma méthode perso de gestion de sauvegarde.

J'utilise systématiquement chaque jour trois jeux de cartouches Zip, lesquelles tournent à tout de rôle régulièrement que je place dans une autre pièce.

En complément je réalise systématiquement une copie de mon dossier (tout entier) de travail.

Bref, j'ai toujours dans un dossier, deux dossiers : celui d'origine (du travail en cours) et la copie.

Si ça tourne au vinaigre sur l'original, alors je supprime ce dossier d'origine et repars sur la copie et renommant comme le dossier d'origine. Puisque cette copie ne peux dater que du lendemain seulement.

Un développeur sérieux, doit savoir que tout dossier et fichier sur son disque dur, peut être potentiellement perdu un jour.

La fameuse loi de Murphy connue aux tout débuts du monde de l'électronique, ensuite de l'informatique...

Bref, ne JAMAIS faire confiance à UN SEUL support. Toujours multiplier les jeux de sauvegardes sur différents supports hors du PC.

Je ne considère aucunement un disque dur partitionné en un support fiable du fait qu'il comporte plusieurs espaces virtuels. Pour moi il ne s'agit que d'UN seul support au niveau fiabilité de sauvegarde ; rien de plus.

Jean-Pierre (plus simplement

)

**ShaiLeTroll** · 19/11/2007, 14h44

Vos idées pour la gestion des sources et des modifications sont effectivement à la portée de tous !
Il y a exactement les mêmes choses pour les professionnels, à la différence qu'il y a des outils pour cela, dont certains sont gratuit en plus !

Delphi 7
Jedi VCS (+ Serveur de Version) ou Tortoise SVN
Mantis (~Bug Tracker)
Final Builder ou MS VSS (Payant les deux)

Jedi permet de versionner chaque unité, avec des commentaires de prise en main et de depot (Check Out / In), cela permet d'éviter que plusieurs personnes s'écrasent leur modification

Tortoise, permet aussi de versionner, d'ajoute un commentaire au dépot, dans le comportement standard, il n'y a pas de prise en main, tout le monde peut faire une modif à tout moment, mais un outil permet de merger deux versions modifiées issues de la même version de la branche

Mantis, c'est un outil qui permet de gérer les bugs mais aussi une road map, et dans le code chaque morceau peut se voir ajouter par commentaire, le numéro du Mantis pour assurer la traçabilité, d'ailleurs, il est interessant de mettre un cartouche dans le commentaire de dépot, indiquant le mantis, puis Jedi et Mantis, peuvent être utilisés par SQL, très utile pour générer automatiquement le ReadMe.txt

Actuellement, on ne le fait pas où je travaille, mais avant, tous les sources étaient gravées sur un CD, ainsi qu'une WMWare (environnement poubellisable à volonté) sur DVD, les disques en deux exemplaires par semaine, un au bureau, un dans un coffre !!!

Enfin, FinalBuilder, si l'on l'utilise au mieux, à chaque version, on ajoute un marqueur de version (comme le fait Microsoft Visual Source Safe), pour définir qu'un ensemble de fichier (un projet cela peut-être 4-5 unité comme 200), et évidemment, une génération d'un zip des sources ET Lib (Interne et Externe) pour retrouver l'environnement en cas de déboggage d'une antépénultième version, et en fonction du système de Serveur de Version et du Client, tu peux aussi récupérer le projet pour n'importe quelle version directement à partir de l'outil, créer de nouvelle branche pour corriger un bug sur une ancinne version distribuée, et bien sur, prévoir de faire la modification (ou merge) dans la version suivante (bcp de version ne vont jamais chez le client, ne passant pas la recette)

Sinon, le "truc pour trouver l'endroit exact de ma dernière écriture de code", grand classique, un "DEMAIN, FAIRE le BIDULE" se retrouve très facilement avec un petit coup de F9, mieux vaut noter en clair, ce qu'il faut faire, si on a oublié où on en était cela peut aider ...

Un truc :
BUT : Ecrire un Code à partir d'un Algo compliqué

Il arrive souvent que l'on aie une fonction un peu compliquée impliquant de nombreuses boucles et conditions, bien sur, on peut faire proprement son algo, sous la forme de schéma (MCT, MOT, ...), mais il est toujours utile de commencer dans le source par écrire l'algo sous la forme de texte (en clair, en français), une fois tout l'algo écrit, il suffit de "remplir" de code entre chaque commentaire, ainsi, on a bcp de chance d'avoir un code de qualité, opérationnel respectant l'algo et commenté !

**Gilbert Geyer** · 19/11/2007, 15h11

Bonjour,

Comme Alainvh Je participe au niveau "ras des pâquerettes" :

BUT : Comment localiser une erreur de logique qui ne provoque pas forcément un plantage ou un message d'erreur:

1 ) Je crée une Form qui comporte un RichEdit si je manque de place dans les Forms du projet.

2) Avant et après le ou les groupes d'instructions que je soupçonne fautives je place des RicheEdit.lines.Add() et des RicheEdit.upDate pour pouvoir suivre l'évolution de valeurs ou de résultats critiques.

3) Pour éviter d'envoyer trop d'infos dans le RichEdit je les précède, si possible, de if ... then pour n'envoyer à la fin de chaque procédure franchie qu'une simple ligne disant par exemple "Procedure tartanpion : bien passé"

4) Avant l'essai suivant suivant je supprime l'envoi des infos inutiles et je rétrécis le domaine des recherches jusqu'à ce que j'arrive à cerner la ligne où cela commence à dérailler.

(un TRichEdit et non un TMemo car on a la possibilité offerte par RichEdit.Print en cas de besoin).

Parfois c'est rapide, parfois c'est la galère, mais comme les compilos ne savent pas détecter toutes les erreurs qu'on peut faire autant se servir de la bécane pour localiser les erreurs.

A+

**alainvh** · 19/11/2007, 15h33

Je procède un peu comme Gilbert Geyer, mais en étant encore plus à "ras des pâquerettes"

Je place un ShowMessage('Ici') et un ShowMessage('Là') de part et d'autre du code qui me semble "dérailler" : puis je resserre cette "tenaille" par dichotomie. En général, je trouve le "bug" assez vite : évidemment, je ne peux pas imprimer de compte-rendu comme le permet RichEdit, mais je n'utilise aucun composant sur la Form !

**Gilbert Geyer** · 19/11/2007, 16h33

Re-bonjour,

A Alainvh : idem pour moi avec un ShowMessage pour les cas simples sauf à l'intérieur d'une boucle où il faudrait cliquer for i:=1 to N fois sur "OK" lorsque N est élevé.

Par contre :

je resserre cette "tenaille" par dichotomie

... Ok sur je resserre cette tenaille dans le cas où un message d'erreur me localise la 2ième moitié de la tenaille, mais par "dichotomie" je ne sais pas faire (???) je procède à l'avancement dans le style "jusqu'ici tout se passe bien" pour voir à partir d'où ça déraille.

Cela m'éclairerait ma lanterne en précisant comment resserrer la tenaille par dichotomie : c'est quoi l'astuce qui se cache derrière le concept dans le cas présent (j'ai beau penser au tri dichotomique je ne vois pas le rapport).

A+

**ShaiLeTroll** · 19/11/2007, 16h38

Pour ma part, j'utilise OutputDebugString qui utilisent le Journal d'évènement de Delphi, mais j'utilise aussi le principe du Memo\RichEdit (j'ai développé une petite fonction Trace, qui affiche les logs de l'appli en temps réel en couleur selon la gravité), le ShowMessage c'est aussi bien pratique (dans une appli converti de DBase à MySQL des opérations DB n'ont pu être comprise et donc traduite, du coup, en mode SUPERUSER, il y a des messages "Je ne sais pas pourquoi, on passe par là" ou "Code non Traduit", et dans l'appli, en fait quelques cas "spéciaux" du coup ne sont plus gérés ...)

**edam** · 12/05/2015, 02h01

Envoyé par Gilbert Geyer

Bonjour,

Comme Alainvh Je participe au niveau "ras des pâquerettes" :

BUT : Comment localiser une erreur de logique qui ne provoque pas forcément un plantage ou un message d'erreur:

1 ) Je crée une Form qui comporte un RichEdit si je manque de place dans les Forms du projet.

2) Avant et après le ou les groupes d'instructions que je soupçonne fautives je place des RicheEdit.lines.Add() et des RicheEdit.upDate pour pouvoir suivre l'évolution de valeurs ou de résultats critiques.

3) Pour éviter d'envoyer trop d'infos dans le RichEdit je les précède, si possible, de if ... then pour n'envoyer à la fin de chaque procédure franchie qu'une simple ligne disant par exemple "Procedure tartanpion : bien passé"

4) Avant l'essai suivant suivant je supprime l'envoi des infos inutiles et je rétrécis le domaine des recherches jusqu'à ce que j'arrive à cerner la ligne où cela commence à dérailler.

(un TRichEdit et non un TMemo car on a la possibilité offerte par RichEdit.Print en cas de besoin).

Parfois c'est rapide, parfois c'est la galère, mais comme les compilos ne savent pas détecter toutes les erreurs qu'on peut faire autant se servir de la bécane pour localiser les erreurs.

A+

je préfére Tmemo sur la forme principal, moin lourd, et avec savetofile

**ShaiLeTroll** · 13/05/2015, 14h10

Pour les versions PRO et plus
OutputDebugString et le journal (Ctrl + Alt + V) intégré dans Delphi fait la même chose et permet aussi d'exporter !

Pour les versions Perso, le Journal, c'est probablement le genre d'outil non fourni

**PapyJohn** · 23/11/2007, 09h59

Petite astuce pour debugger un projet
Aller dans Projets options
DÉSACTIVER l'optimisation (choix implicite)
ACTIVER les trois erreurs à l'exécution
ACTIVER les cinq options de debug

Et quand vous compilez traitez les messages d'avertissement
Pris un par un ils n'ont que peu d'importance (d'où leur claassificatio)
mais leur combinaison peut générer à terme un bug beaucoup plus sournois a identifié (les effets de bord par exemple)

L'ennemi le plus redoutable est le gestionnaire de mémoire Il est assez redoutable a debuger.
Le meilleur moyen est de s'en passer au maximum aussi préférer toujours une variable de taille fixe globale a une dynamique locale.
Il sera toujours temps quand votre projet sera au point de mettre en dynamique se qui peut l'etre et si cela se passe mal vous identifirez beaucoup plus facilement l'opération provoquant le bug.

Bon debbug
'Heureusement que l'on commets des erreurs : où serait le plaisir de la programmation si tous marchait du premier coup?

PapyJohn

**Montor** · 08/06/2009, 12h50

Expressions regulieres pour Delphi

http://www.regular-expressions.info/...TPerlRegEx.zip

**Droïde Système7** · 22/07/2009, 11h51

Si un jour, avec bien plus d'expérience engrangée au fil des ans, il vous arrive de modifier radicalement une fonction ou procédure ; surtout gardez-en une trace !

Par exemple juste au dessus de la fonction ou procédure remaniée. Laissez cet bloc-old sous commentaires.

De cette façon, si pour un oui ou un non, par la suite, vous avez directement ou bien indirectement, des soucis sur un bloc de code qui auparavant fonctionnait, mais qui désormais pose des difficultés ; vos recherches en seront grandement facilitées.

Suffira tout simplement et rapidement, de remplacer le ou les blocs en question afin de comparer.

L'auteur de ces lignes vient d'en faire une cuisante expérience. En effet sur une appli distribuée à des centaines d'unités par mois, seul deux utilisateurs éprouvaient de méchants blocages.

Sous mon Vista et sous le XP de mes testeurs ; tout était en RAS.

Mais le plus difficile et redoutable pour un développeur, n'est-il pas de détecter un bug qu'il ne peut détecter lui-même ?

@+

**Paul TOTH** · 22/07/2009, 12h50

Envoyé par Droïde Système7

Si un jour, avec bien plus d'expérience engrangée au fil des ans, il vous arrive de modifier radicalement une fonction ou procédure ; surtout gardez-en une trace !

ben...c'est pas un peu à ça que sert le versioning ?

**Franck SORIANO** · 22/07/2009, 13h18

Envoyé par Paul TOTH

ben...c'est pas un peu à ça que sert le versioning ?

Plus exactement : La gestion de configuration. Bon d'accord, je joue sur les mots...

**Droïde Système7** · 22/07/2009, 14h08

Envoyé par Paul TOTH

ben...c'est pas un peu à ça que sert le versioning ?

Paul, tu emploies des mots inconnus aux débutants ; ici ce mot est trop compliqué, voire alambiqué

Ce thread s'adresse aux débutants, et non aux experts ; dont tu fais partie.

PS : Franck, merci de cet éclairage ; c'est en effet bien plus parlant.

Je faisais alors du versioning sans le savoir, comme Monsieur Jourdain...

**Paul TOTH** · 22/07/2009, 14h42

Envoyé par Droïde Système7

Paul, tu emploies des mots inconnus aux débutants ; ici ce mot est trop compliqué, voire alambiqué

ben justement, comme ça un débutant pour s'intéresser au sujet s'il rencontre le problème

**dd_garion** · 22/07/2009, 15h38

Pour continuer dans la série des Ctrl bien utile

On sélectionne le text et on tape Ctrl + KN pour mettre en majuscule (bien pratique quand on a des requêtes SQL et que les champs sont en "case sensitive".

Celui qui connait sont contraire m'interesse

PS : existe t'il un endroit où tout ces raccourcis claviers sont repris ?