Techniques et astuces de programmation pour débutants et "confirmés", Partagez ici vos techniques et astuces pour mieux programmer

[macuserfr]

Bonjour à tous,

Nous voyons souvent sur ce forum des sujets demandant comment débuter en programmation, ou quel langage pour débuter. Ici je voudrais traiter d'un sujet connexe mais peu (pour ne pas dire pas) abordé: les méthodes et bonnes pratiques de programmation, indépendamment du langage.

Connaître un (voire plusieurs) langages de programmation est certes important pour programmer. Mais en dehors de sa syntaxe et grammaire, il y a plein de choses qui viennent en amont et qui permettent de coder plus vite ou plus efficacement. Certains points seront bien sûr sujets à de controverses, donc je demande par avance aux représentants des divers courants de pensée en conflit de présenter leurs arguments SANS rentrer dans des débats sans fin. Vous l'aurez compris, je demande votre participation pour enrichir ce fil, car je ne prétend pas avoir la science infuse ni tous les bons conseils à donner.

Ceci étant dit, voici un liste non exhaustive pour commencer:

• Réfléchir au problème et le modéliser avant de coder. Je citerai encore un de mes profs: "Le plus tôt vous commencez à coder, le plus tard vous finirez". Quand vous avez un nouveau programme à résoudre, commencez par le découper en boites gérant une partie de votre code de la façon la plus autonome des autres. Déroulez votre programme à la main sur une feuille de papier en pensant à tous les cas de figure qui peuvent se produire. Il n'y a qu'une fois que vous avez ce squelette clair dans votre tête que vous pouvez commencer à le coder.

• Nommez de façon propre vos variables et vos fonctions. D'une part, il faut que le nom soit en rapport avec ce que fait la variable/fonction (évitez var1, var2, toto, titi, tmp). D'autre part, prenez une convention de nom et tenez-vous y. Certain langages imposent une convention genre maFonction, MaClasse. D'autres ce sera ma_variable. Pour ceux qui n'en imposent pas, choisissez-en une.

• Des commentaires utiles! Inutile de raconter un roman pour décrire une fonction. Pour un commentaire de fonction dites en 2 lignes maximum ce qu'elle fait (si ça tient pas sur 2 lignes, c'est que votre fonction est trop compliquée et qu'il faut la découper pour faire plus simple) puis dire ce qu'on attent en arguments et quelle est la valeur de retour, en explicitant les valeurs particulières genre: "retourne la valeur de A, ou null en cas d'erreur"

Pour des commentaires de code, ne paraphrasez pas le code, c'est inutile, ça fait perdre du temps et à vous et au lecteur! Dites plutôt ce que vous voulez en faire:

Code

//Commentaire inutile: si a égal b ou b égal c
if(a == b || c==b)

Code

//Commentaire utile: si b appartient à l'ensemble
if(a == b || c==b)

Vous n'avez pas besoin de tout commenter, je dirait que commenter les fonctions et les passages difficiles c'est suffisant si le code a été bien découpé en fonctions.

• Avoir des notions d'algorithmique pour optimiser ses programmes

• Faire des test unitaires

• Indenter proprement son code

[Jaypee]

Bravo. C'est un très beau sujet.

Il faut noter que certains environnements pour le développement en Java apportent de nombreux outils allant dans ce sens.
Ayant plus d' expérience Java que C++, j' apporterai volontiers ma contribution. Il y a des pratiques qui commencent à se généraliser dans les différents langages à objets et il sera intéressant de faire des parallèles.

Il y a aussi les bibilothèques tellement utiles qu'elles devraient exister dans tous les langages. On pourrait faire l'état des lieu.
(gestion des "logs" par exemple)

à suivre,
J-P

[Hellstorm]

Lors d'une condition d'égalité avec une constante, mettre la constante à gauche, comme ça si par mégarde on oublie un égal le compilo nous sort une erreur.

ex :

Code

if (MA_CONTANTE == a)

au lieu de :

Code

if (a == MA_CONTANTE)

Ce message a été modifié par Hellstorm - 27 Jul 2009, 08:30.

[noop]

Je me lance:

La documentation des programmes: pour moi la documentation externe d'un programme est 99% du temps inutile. Mieux vaut des commentaires pertinents dans les sources plutot qu'un document qui ne sera jamais remis a jour lors de l'évolution des sources. Pour le 1% restant, une documentation sur des points complexes est nécessaire

Concernant le langage C:
- éviter de mettre plusieurs instructions sur une seule ligne.
- utiliser les accolades dans les instructions if, do while, while etc.... Combien de fois j'ai vu une correction rapide devenir un vrai cauchemar a cause de celà

Code

// avant modif
if (...)
     instruction;

Code

// après modif
if (...)
     instruction;
     instruction_ajoutée_en_pensant_quelle_sera_exécutée_dans_le_then_implicite;

Code

// préférable !!!
if (...) {
     instruction;
}

Gestion de la mémoire: se fixer une règle et une seule pour les fonctions utilisateurs (pour les fonction système appliquer les règles des déveloper guides)
- l'appelant est propriétaire de la mémoire
- ne jamais faire confiance à l'appelant

Allocation mémoire: A moins d'écrire des programmes pour la fusée Ariane, il est inutile de tester si la zone allouée est nulle. Exemple:

Code

char * maChaine = (char *) malloc(sizeof(char) 10);
if (maChaine == NULL) {
   // ce test est inutile
}

Si le système n'est pas capable de vous allouer 10 caractères, le code qui va être exécuter dans le test va nécessiter lui aussi de la mémoire et peut être même plus que 10 caractères.....il va donc aussi planter. Un système auquel il manque 10 c est à genoux et va planter dans peu de temps.

Gestion des erreurs: La gestion des erreurs et des logs DOIT être mise en place au tout début d'un projet. J'ai trop souvent vu des programmes qui font du printf() ou du System.out.println(). Quand il faut tout réécrire ca plombe tout.

[Hellstorm]

Tiens au niveau des acolades je suis tout à fait d'accord avec toi noop, mais pas sur leur placement, personellement je trouve le code beaucoup plus lisible lorsque les acolades sont alignées :

Code

if (...)
{
   instructions;
}

Bon après ce n'est que mon avis.

[macuserfr]

J'suis plutôt pour les accolades alignées selon l'exemple de Hellstorm, à moins d'avoir une contrainte de place (genre petit script php dans du code HTML que tu veux pas faire occuper toute la page), ou sinon passer à Python et plus avoir d'accolades du tout (je ne l'ai personnellement pas fait, mais il paraît que c'est un bonheur.)

[noop]

Déclaration des blocs en C/C++: Effectivement j'écris les blocs de la manière suivante:

Code

if (...) {
   ...
} else {
   ...
}

En fait je ne fais que suivre ce qui était fait dans la norme C99. Mais je peux me tromper.

[macuserfr]

Je dirais que plus important qu'utiliser une forme ou l'autre, c'est d'utiliser toujours la même forme, pour avoir un code cohérent et lisible.

[Sedutom]

Ce n'est pas une obligation mais je préfère quand toutes les déclarations de variables sont regroupées au début du programme (dans certains langages c'est même obligatoire). Comme il l'est dit plus haut, le nom des variables doit être clair et si possible commentés (au moins par groupe) :

Code

//Vitesses des ondes de volume
double vitesseP;
double vitesseS;
//Fichiers
FILE *fichierIn;
FILE *fichierOut;

Lors de la lecture du code on pourra alors avoir la liste des variables facilement accessible. De plus, le code est plus lisible quand on sait quelle est l'utilité d'une variable.
Cela diminue aussi le risque d'oublier de déclarer une variable.

[bad_duck]

Je ne sais plus d'où ça sort (un mec de chez IBM à l'époque je crois) :

" Si on ne peut pas comprendre l'utilité d'un programme en lisant uniquement les commentaires, alors vous pouvez jeter l'ensemble du code ! "

[Jaypee]

La règle des accolades doit être fixée collectivement, l'une ou l'autre est correcte, ensuite il faut avoir moyen d'automatiquement formatter le source selon cette règle. Avec Eclipse, il y a un réglage pour le choisir et le raccourci c'est ctrl-alt-F

Mais idéalement tous les sources dans (CVS, SVN...) doivent avoir la même présentation. Dans le même ordre de choses, il faut voir s'il faut ajouter une entête avec copyright.

J-P

Ce message a été modifié par Jaypee - 27 Jul 2009, 13:14.

[noop]

Un petit guide pour tout langage qui s'apparente au langage C ou qui utilise le C:

Guide Superflu de programmation en langage C

Ce message a été modifié par noop - 27 Jul 2009, 13:50.

[Hellstorm]

Pour ce qui est des conventions de nommage, je trouve la notation hongroise pratique (toujours en C/C++)

[macuserfr]

12 réponses et 140 lectures pour un post qui a environ 24h, c'est pas mal tout ça

@noop -> Pas mal le PDF de ton lien

[Jaypee]

En C/C++, mettre les #define tout en majuscules et parenthéser sans parcimonie

L'exemple de Feuer dans le "C Puzzle book"est la macro :
#define NEG(x) -x

Si x est négatif, selon le compilateur, cela donne vraiment la valeur absolue ou bien --x.

Donc la bonne pratique est :
#define NEG(x) -(x)

J-P

[Vin's]

Lors d'une condition d'égalité avec une constante, mettre la constante à gauche, comme ça si par mégarde on oublie un égal le compilo nous sort une erreur.

ex :

Code

if (MA_CONTANTE == a)

au lieu de :

Code

if (a == MA_CONTANTE)

Dans le cas de gcc, quelque chose comme "if (a = 3) ..." donne un avertissement lorsque -Wall est utilisé :

warning: suggest parentheses around assignment used as truth value

Donc personnellement, je préfère mettre la constante à droite.

[chombier]

En C/C++, mettre les #define tout en majuscules et parenthéser sans parcimonie

Je dirais même plus, en C++, éviter à tout prix les macros #define et les remplacer par des fonctions inline.

[edit]
une illustration de mon propos:
http://www.parashift.com/c++-faq-lite/inli...ns.html#faq-9.5
[/edit]

Ce message a été modifié par chombier - 27 Jul 2009, 14:56.

[Phil J. Fry]

• Indenter proprement son code

En Python, il est utile de mettre des commentaires de dédentation :

Code

....
for i ... :
    for j ... :
        ....
        ....
    # end for j
    ....
    ....
#end for i
....

[Hellstorm]

Lors d'une condition d'égalité avec une constante, mettre la constante à gauche, comme ça si par mégarde on oublie un égal le compilo nous sort une erreur.

ex :

Code

if (MA_CONTANTE == a)

au lieu de :

Code

if (a == MA_CONTANTE)

Dans le cas de gcc, quelque chose comme "if (a = 3) ..." donne un avertissement lorsque -Wall est utilisé :

warning: suggest parentheses around assignment used as truth value

Donc personnellement, je préfère mettre la constante à droite.

Ahh j'avais jamais vu que gcc pouvait emettre un warnng pour ça, merci Vin's

[mpergand]

Code

Code
// préférable !!!
if (...) {
     instruction;
}

Tiens au niveau des acolades je suis tout à fait d'accord avec toi noop, mais pas sur leur placement, personellement je trouve le code beaucoup plus lisible lorsque les acolades sont alignées :

Code

if (...)
{
   instructions;
}

Bon après ce n'est que mon avis.

Les gouts et les couleurs ...

Extrait de Guide du développement logiciel par Timothée Royer

Présentation des accolades
Une paire d’accolades délimite un élément de structure.
*** IMPÉRATIF ***
Une accolade fermante se trouve toujours à la verticale de l’accolade ouvrante correspondante.
(Exemple) A ne pas faire :

Code

int main(void)
{
    cout << "Les codes ASCII :" << endl;
    int col;
    for(int ligne = 0; ligne < 32; ligne++) {
        for(col = 0; col < 7; col++) {
            cout << (col*7+ligne) << ' '
                << char(col*7+ligne) << '\t';
        }
        cout << endl;
    }
}

Cette disposition permet de gagner deux lignes de code source. Elle fait cependant moins ressortir la structure logique du code. Elle n'est donc pas souhaitable. Le code source doit plutôt être présenté comme ceci :

Code

int main(void)
{
    cout << "Les codes ASCII :" << endl;
    int col;
    for(int ligne = 0; ligne < 32; ligne++)
    {
        for(col = 0; col < 7; col++)
        {
            cout << (col*7+ligne) << ' '
                 << char(col*7+ligne) << '\t';
        }
        cout << endl;
    }
}

En fait, dans la suite du doc, il utilise la même disposition que celle que j'utilise depuis plus de 20 ans, celle-ci:

Code

int main(void)
    {
    cout << "Les codes ASCII :" << endl;
    int col;
    for(int ligne = 0; ligne < 32; ligne++)
        {
        for(col = 0; col < 7; col++)
            {
            cout << (col*7+ligne) << ' '
                << char(col*7+ligne) << '\t';
            }
        cout << endl;
        }
    }

Cette disposition est pour moi la seule logique, car je ne trouve aucunes raisons pour que les accolades ne soient pas aux même niveau que les instructions qu'elles délimitent.


Ce message a été modifié par mpergand - 27 Jul 2009, 22:08.

[noop]

je propose d'ouvrir un sujet identique sur les "bonnes pratiques quant au placement des accolades"

[chombier]

Les gouts et les couleurs ...

Toutafé... ceci est une histoire de goût et n'a absolument rien à voir avec la programmation. Il y a eu une tentative de conciliation de l'indentation avec Python, mais même là, on trouve encore des râleurs qui hurlent contre l'indentateur ( ) à 2 colonnes, alors qu'ils en utilisent 4. Les ayatollah de l'indentation ont encore de beaux jours devant eux.
Plus simplement: chacun voit midi à sa porte, et ça risque de durer longtemps, et le compilateur s'en tape.

[macuserfr]

Bon, si tout le monde est d'accord pour dire que le chapitre accolades est clos, passons à un autre

Je propose de parler de variables: Il est de bon usage de mémoriser le résultat d'une opération dont on va se resservir plus tard pour économiser du cpu tout en utilisant un poil plus de mémoire. Ex:

Dans un code qui fait plusieurs fois appel à la longueur d'une chaîne de caractères, au lieu de faire appel sans cesse à une fonction strlen (longueur de la chaîne), on stocke son résultat une fois et on utilise notre variable ensuite (à moins que la longueur ai changé). L'utilisation d'une variable est bien moins coûteuse qu'un appel de fonction. Donc on fait un:

len = strlen(machaine);

Et ensuite, au lieu de réutiliser l'appel strlen() on utilise len.

Cela vaut aussi, je crois, quand on a besoin d'une information précise (une taile, par exemple) dans une structure de données complexe. Genre un tableau de plusieurs structures, chacune des structures comportant des sous-couches. Même principe, au lieu de faire plusieurs appels à des trucs infâmes du genre monTableauDeStruct[0]->Aile->quantiteDeCarburant, tu prends la quantiteDeCarburant dans une variable temporaire, tu travailles dessus et tu actualises le résultat à la fin de la fonction.

[noop]

Cela vaut aussi, je crois, quand on a besoin d'une information précise (une taile, par exemple) dans une structure de données complexe. Genre un tableau de plusieurs structures, chacune des structures comportant des sous-couches. Même principe, au lieu de faire plusieurs appels à des trucs infâmes du genre monTableauDeStruct[0]->Aile->quantiteDeCarburant, tu prends la quantiteDeCarburant dans une variable temporaire, tu travailles dessus et tu actualises le résultat à la fin de la fonction.

Je préfèrerais le code suivant:

Code

long * tempQuantitéCarburant = &(monTableauDeStruct[0]->Aile->quantiteDeCarburant);
....
*tempQuantiteCarburant += quantité;
....
*tempQuantiteCarburant += 10;

La mise à jour est automatique.....Un oubli est si vite arrivé

Concernant les variables, il y a une erreur très fréquente qui est la suivante:

Code

char * maFonction() {
   char maChaine[100];
   ...
   return maChaine;
}

Ne jamais retourner de pointeur sur la pile. Le résultat est "unpredictable" et en plus des problèmes de sécurité la donnée n'est pas fiable. En plus un appel a free() sur ce pointeur est une catastrophe.

[macuserfr]

Oui, les pointeurs!

Par contre dans ton deuxième exemple, maChaine est une variable locale, donc théoriquement détruite à la fin de la fonction. On est pas censé y accéder après.

[Hellstorm]

Comme tu dis macuserfr, on est pas censé, d'ou l'avertissement en de noop

[macuserfr]

Tiens, une astuce toute bête à laquelle je viens d'être confronté: Si vous avez une variable ou autre bout de chaîne à changer dans votre code, utilisez la fonction de recherche de votre éditeur de texte/IDE pour localiser toutes les instances. Si vous le faite à la main, vous pouvez en oublier...

[Hellstorm]

Ouaip, mais y a même mieux, du style rechercher et remplacé ça evite de devoir retaper X fois le même nom de variable, il faut rappeler que l'informaticien est fénéant

[macuserfr]

Oui, oui, quand je disais la fonction recherche, j'ai fait un remplacer et rechercher. J'ai pas osé un remplacer tout car ça peut vite dégénérer aussi dans l'autre sens...

[greg57]

Bon euh... si c'est pour conseiller de faire du rechercher remplacer je suis plus du tout sur de vouloir l'épingler ce sujet...

[macuserfr]

Zut alors! Le niveau baisse... Vite les gars, proposez un bonne astuce pour qu'on finisse épinglés!

[bad_duck]

Ouep le rechercher / remplacer est plus que risqué si il change plus de chose que tes variables ou tes fonctions (dommages collatéraux), c'est pourquoi certains IDE changent automatiquement les références à une variables / fonctions quand tu en change le nom (de mémoire netbeans le fait).

Sinon le sujet du topic est assez vague et dépend principalement du langage qu'on utilise.

[macuserfr]

On est beaucoup parti sur le C, mais je pensai un peu à m'abstraire au langage. Pour être un bon programmeur il faut de la logique, de la rigueur. Avoir une capacité de schématiser, de concevoir sans même avoir pondu une ligne de code. c'est plutôt des trucs et astuces là dessus que je pensais, avec surtout un retour d'expérience de ceux qui "ont de la bouteille" (dans le bon sens du terme) pour dire "ça ça marche, ça c'est de la c** vous pouvez oublier".

Après, pourquoi pas quelques astuces sur des langages aussi. Mais le but ce n'est pas de faire une n-ème "guerre de langages", il y a déjà beaucoup de topics là dessus.

Donc on pourrait recentrer le débat sur comment coder plus vite, plus efficacement, plus proprement.

[greg57]

Ben dans ce cas c'est plus du codage c'est de l'algorithmique non ?

[macuserfr]

Oui, une grande partie d'algo, mais pas seulement, tout ce qui fait partie d'un projet de programmation en dehors du code bête et méchant, cela peut aussi être l'organisation du travail, bien définir le cahier de charges avant de commencer le projet, ...

[bad_duck]

http://fr.wikipedia.org/wiki/Méthode_agile
http://fr.wikipedia.org/wiki/Patron_de_conception

[noop]

Voici un exemple de bout de code qui écroule toutes les perfs dans un programme. Pourtant ca part d'une bonne intention

Code

void maMethodeDeTrace(String message, int niveauDeTrace) {
       if (niveauDeTrace < niveauDeTraceGlobal) {
            logger.trace(message);
       }
}

Voici le code Appelant:

Code

maMethodDeTrace(monObject.toString(), 2);

Le problème est le suivant: avant de faire l'appel à la méthode maMethodeDeTrace, le langage va évaluer le premier parametre. Si le niveau de trace est insuffisant rien ne sera tracé, mais on aura perdu du temps a transformer un object en chaine de caractère. Si cet appel se répète trop souvent, le programme va ramer un max.

[Jaypee]

Dans ce cas, il faut une API du style boolean isNiveauDeTraceSuffisant(int niveauSouhaite);

Les Loggers ont des primitives Logger.isDebugEnabled() dans ce même but.

A propos des remplacements multiples, c'est une illustration du proverbe que je cite souvent :
Un programmeur est un paresseux qui travaille beaucoup.

Par paresse, il va se donner la peine de trouver l'expression régulière qui va magiquement remplacer son motif dans toutes les configurations les plus tordues. Ce proverbe n' est pratique que si on se demande "Mais que ferait un bon programmeur dans cette situation ?" Il va étudier et retenir tous les trucs tordus, qui parfois vont lui faire gagner 10% du temps. C'est pour cela qu'il apprend toutes les commandes de <choississez l' éditeur que vous détestez le plus>

Au passage, des trucs d'édition...
Qui connaît la commande "deep" dans vi ?
de : delete to the end
e : go to the end
p : paste colle à droite du curseur
Elle permute deux mots.
et xp ? "xp" fait la même chose pour 2 caractères
x : delete du caractere sous le curseur, qui se trouve maintenant sur le caractère suivant
p : paste colle à droite du curseur

Et puisqu'on est sur le sujet des recherches, la commande vi pour remplacer tous les x par y, partout dans la ligne
:g/x/s//y/g

Le premier g est pour indiquer toutes les lignes, le dernier pour "partout dans la ligne", si on l' oublie, seul le premier remplacement est fait dans la ligne.

Le s c'est pour substituer

C'est la version simplifiée de remplacer tout les x par des y, partout dans les lignes où se trouve z
:g/z/s/x/y/g
La forme compliquée de la première serait : sur toute lignes où il y a x, remplacer x par y. Du fait que le motif de recherche des lignes est aussi le motif à remplacer, on peut l'omettre après le s.

J'ai appris tout ça par paresse...

J-P

Ce message a été modifié par Jaypee - 28 Jul 2009, 20:11.

[macuserfr]

J'arrive pas à m'y faire avec les éditeurs en ligne de commande. Certes, je reconnais qu'un pico ou autre pour remplacer une virgule dans un script qui est en root ça va plus vite que de prendre le script, ouvrir dans l'interface graphique en non-root (oui, d'accord, t'as des astuces pour le faire en root) puis sauvegarder en non-root et recopier en root à son endroit d'origine. Vous me suivez encore?

Pour mes petits développements je passe par Smultron que je trouve simple et efficace. J'ai vu TextMate dans une video de présentation de Python, qui a l'air bien aussi. Pourquoi ne pas les utiliser sur des stations graphiques? D'accord qu'en ssh ou sur un serveur ou t'as qu'une CLI ça se corse, mais bon, ma station de développement de base c'est un Mac.

Sinon, là il va falloir que je debug du php, donc à ce que j'ai compris, pas trop le choix, le mieux c'est d'installer l'usine à gaz qu'est eclipse PDT.

[bad_duck]

J'arrive pas à m'y faire avec les éditeurs en ligne de commande. Certes, je reconnais qu'un pico ou autre pour remplacer une virgule dans un script qui est en root ça va plus vite que de prendre le script, ouvrir dans l'interface graphique en non-root (oui, d'accord, t'as des astuces pour le faire en root) puis sauvegarder en non-root et recopier en root à son endroit d'origine. Vous me suivez encore?

Pour mes petits développements je passe par Smultron que je trouve simple et efficace. J'ai vu TextMate dans une video de présentation de Python, qui a l'air bien aussi. Pourquoi ne pas les utiliser sur des stations graphiques? D'accord qu'en ssh ou sur un serveur ou t'as qu'une CLI ça se corse, mais bon, ma station de développement de base c'est un Mac.

Sinon, là il va falloir que je debug du php, donc à ce que j'ai compris, pas trop le choix, le mieux c'est d'installer l'usine à gaz qu'est eclipse PDT.

Apprendre à utiliser un éditeur en cli (vim, nano ou autre) est assez pratique pour les machines qui n'ont pas d'interface graphique (les serveurs MacBidouille par ex), surtout quand tu as juste des petites modifications à faire (décommenter une ligne, changer un p'tit param etc..).

Textmate est un super éditeur de texte, je m'en sers pour faire du xhtml/php/css etc.. et pour le debug php je vois pas trop l'intérêt d'éclipse : t'as simplement besoin d'un serveur web qui supporte php : si ya pas de warning ou de notice : c'est bon ; si la page te sort un gros warning tu regarde la ligne et tu vas débugger avec ton éditeur de texte

[macuserfr]

Pour les éditeurs texte, on est d'accord

Pour le debug de PHP, oui, tu peux faire comme cela, voire même mettre des echo/var_dump dans ton code (ce que je fais actuellement). Mais il y a des fois ou ce serait pratique d'avoir un vrai debugger à la gdb, pouvoir passer toutes les variables en revue. Quand tu comprends le bug, c'est simple, comme tu dis tu va à la ligne où il faut et tu changes l'instruction qu'il faut.

Mais quand t'as des trucs tordus, t'es bien content de pouvoir exécuter ton code pas à pas et voir le changement d'état des variables jusqu'à capter où est le problème. C'est là que les outils de débogage d'eclipse entrent en jeu.

Je suis d'accord pour dire que si tu codes proprement et avec de l'expérience, t'es pas censé avoir des comportements tordus en test. Mais en phase d'apprentissage et prise en main des outils cela me semble inévitable. Le php est loin d'avoir toutes les "bizarreries" du C, il a aussi quelques particularités auxquelles il vaut mieux faire attention.

[Hellstorm]

Personellement pour coder du C/C++ je me sers de xcode, après pour le reste je rejoins macuserfr sur smultron qui est léger et simple d'usage, TextMate est payant si je ne m'abuse..
Sinon en CLI, je trouve nano très simple pour des petites éditions rapides, je n'ai personellement pas accroché VIM.

[macuserfr]

Pareil, pour mes gros projets en C pendant les études je suis passé par XCode que j'ai maitrisé assez rapidement pour debugger avec un GUI sur gdb, c'était le bonheur. J'ai des copains qui se cassaient les dents avec gdb (qui fait théoriquement la même chose, mais qui est plus austère à maîtriser) ou avec KDevelop qui à l'époque n'était pas aussi simple que XCode. Eclipse en était à ses débuts, surtout focalisé sur Java.

Il y en a plus d'un qui a bavé sur mon iBook et ce que je pouvait faire (simplement) avec pour debugger.

[Jaypee]

J'avais signalé un problème de Smultron que je trouve important : De tous les éditeurs courants, c'est le seul qui ne signale pas qu'un document ouvert a été modifié et donc le seul à ne pas proposer de le recharger. C'est un risque important de réimporter des bugs déjà fixés.

A mon avis, c'est rédhibitoire pour un usage "pro", mais il reste très bien pour des utilisations occasionnelles.

TextMate a un tel impact qu'il existe une personnalisation d'Eclipse qui reprend son thème de couleurs, et de même pour jEdit.

Etant sur du Java principalement, je travaille avec Eclipse qui est vraiment très, très puissant :
- Propose les noms de méthodes après le point (à la Intellisense)
- Import automatique des bibliothèques
- Nettoyage des imports non utilisés
- Formattage automatique (des accolades...) selon les règles fixées
- Géneration des commentaires Javadoc.
- Generation des getters/setters des propriétés.
- Refactoring
- ...

J-P

Ce message a été modifié par Jaypee - 29 Jul 2009, 11:43.

[Hellstorm]

Je ne suis pas sur, mais il me semble que dans les options avancés de smultron il y a une option pour vérifier si un document ouvert à été modifié (je ne peux vérifier en ce moment étant windows :<)

[macuserfr]

Oui, l'option existe sur la dernière version (3.5.1) mais décochée par default, je viens de la cocher
Ceci dit, je ne m'aventure pas à éditer mes codes avec 2 éditeurs en même temps. Même si c'est techniquement possible, c'est très casse-gueule comme méthode.

[Vin's]

Une petite bibliothèque qui facilite le déboguage des allocations mémoire en C : Electric-Fence.
Par exemple, si l'on a le code suivant :

Code

int* tab = malloc(10 * sizeof(int));
tab[10] = 42; /* ERREUR tab a 10 éléments, de 0 à 9 */

Généralement, un débordement de tableau comme celui-ci ne fera pas planter immédiatement le programme. Mais il pourra provoquer des plantages plus tard, à cause de la corruption mémoire engendrée...
Le but d'Electric-Fence est justement de faire planter le programme dès qu'il provoque un débordement de tableau.
Il fonctionne bien sous Mac OS X... Il suffit de lier le programme que l'on débogue à la libefence (et éventuellement mettre la variable d'environnement EF_PROTECT_BELOW à 1 si l'on veut que Electric-Fence surveille aussi les sous-débordements), et c'est bon

Attention, cet outil ne vérifie pas les allocations mémoire faites sur la pile (comme "int tab[10]"). Pour vérifier ça (ainsi que beaucoup d'autre choses...), il y a Valgrind (mais seulement sous Linux...)

Ce message a été modifié par Vin's - 30 Jul 2009, 08:59.

[noop]

Quand on fait du développement en C/C++ multi tache, débugger un programme qui crash est quelque fois impossible. En effet, si l'on pose un break point dans une thread, on change le comportement de l'ensemble du processus (si celui-ci a été mal architecturé par rapport aux mécanismes de rendez vous ou d'attente sur sémaphore). L'unique solution est quelque fois d'utiliser des debugger "post-mortem".

Le principe est simple, le programme est compilé avec un bout de code qui provoque un "dump" en cas de crash.

Le dump une fois récupéré peut être analysé avec le debugger. A charge du développeur de fouiller ses stack et la mémoire pour trouver ce qui cloche.

[macuserfr]

Un peu HS, mais à l'école d'ingé où j'ai été le Linux était configuré de base pour générer ces dump lors d'un crash. Or nous avions un quota très restrint (du genre 30Mo). Du coup on avait un config à mettre dans notre .profile pour éviter de créer ces dump et de bloquer notre session si on était un peu juste niveau quota.

[cbrandt]

En C/Objective-C je mets toujours cette petite macro pour faciliter le traitement des erreurs:

Code

#define Fail(erreur,label) {if(erreur) goto label;}

oui, je sais, les goto c'est crade, mais c'est pour la bonne cause
Ça permet de regrouper le code de gestion d'erreur en fin de fonction, et ça s'utilise comme ça:

Code

int err;
...
err = appel_de_fonction ();
Fail (err, stop);
...
return;
stop:
NSLog (@"erreur: %d", err);
...

[macuserfr]

Pourquoi faire du goto et des labels quand un

Code

if(!fonction())
{
    //traitement de l'erreur
}
//continuation du code

fait la même chose en plus propre (en supposant que la fonction retourne 0 si erreur)?

Si plusieurs morceaux ont besoin du même traitement d'erreur, dans la partie traitement d'erreur dans le if il suffit de faire un appel vers une fonction dédiée à la gestion d'erreur (c'est même recommandé). Cela revient au même effet que ta macro, mais en plus propre et lisible.

[cbrandt]

je m'explique

si on a juste un ou deux appel de fonctions, ton exemple est ok, c'est comme ça que je fais aussi.
mais si on a un enchaînement de plusieurs fonctions qui renvoient un code d'erreur, on aurait le cheminement normal encombré (visuellement) de traitement d'erreur:

Code

if(!fonction1())
{
    //traitement de l'erreur
}
if(!fonction2())
{
    //traitement de l'erreur
}
if(!fonction3())
{
    //traitement de l'erreur
}
//continuation du code

alors que comme ça c'est plus clair (à mon avis):

Code

err = fonction1 ();
Fail (err, stop);
err = fonction2 ();
Fail (err, stop);
err = fonction3 ();
Fail (err, stop);
//continuation du code
return;
stop:
// traitement erreur(s)

par ailleurs, si une fonction renvoyant une erreur implique que la fonction qu'on écrit doit finir en erreur aussi, ça permet de faire le ménage proprement et dans l'ordre:

Code

mafonction()
{
int err;
char *buffer;
FILE *file;

err = fonction1 ();
Fail (err, stop1);

buffer = malloc (xxx);

err = fonction2 ();
Fail (err, stop2);

fichier = fopen ("chemin", r);

err = fonction3 ();
Fail (err, stop3);

err = fonction4 ();
Fail (err, stop4);

fclose (fichier);
free (buffer);

// suite du traitement

return; // ok - avec éventuellement un code pour indiquer le succès

stop4:
stop3:
    fclose (fichier);
stop2:
    free (buffer);
stop1:
    // gestion erreur
    return; // avec éventuellement un code erreur
}

si l'appel à fonction2() échoue, on désalloue buffer mais on ne touche pas à fichier - et si ça échoue sur fonction3() ou fonction4(), on ferme fichier d'abord, puis on désalloue buffer…

mais bon, il y a toujours plusieurs façons de faire, et chacun préfère la sienne

Ce message a été modifié par cbrandt - 14 Aug 2009, 14:18.

[noop]

je m'explique
si l'appel à fonction2() échoue, on désalloue buffer mais on ne touche pas à fichier - et si ça échoue sur fonction3() ou fonction4(), on ferme fichier d'abord, puis on désalloue buffer…

mais bon, il y a toujours plusieurs façons de faire, et chacun préfère la sienne

Code

stop3:
    fclose (fichier);
stop2:
    free (buffer);

Mieux vaut ca:

Code

stop3:
     if (fichier != NULL) {
    fclose (fichier);
     }
stop2:
     if (buffer != NULL) {
    free (buffer);
     }

Ce message a été modifié par noop - 14 Aug 2009, 14:34.

[cbrandt]

Bien vu
j'aurais dû ajouter un appel à Fail() après malloc() et après fopen()...

Fail (buffer == nil, stopXXX)

et

Fail (file == nil, stopXXX)

[Jaypee]

Sur ce coup, j'suis sceptique. Si le langage offre un try/catch/finally c'est quand même plus propre.

Mais si effectivement ça manque, c'est une bonne béquille.

La leçon essentielle qu'il faut retenir de cet exemple est que le programmeur est souvent focalisé sur la gestion mémoire, allouer, rendre les blocs, mais oublie les autres ressources système qu'il utilise:
- Les fichiers ouverts
- Les connections ouvertes (Connection pools des serveurs bd)
Il faut aussi les restituer.
En fait, ici faudrait simuler en plus le bloc finally dans lequel on passe toujours, succès ou erreur. Et c'est là qu'il faut tester si File est null sinon le fermer etc...

C'est qui conduit à bloquer une machine et à devoir la redémarrer.

[macuserfr]

Oui, je suis sceptique aussi. En effet des try catch dans un langage qui le permet c'est prévu pour. Sinon tu peux toujours te débrouiller pour avoir des fonctions et un switch pour réaliser ces codes là au lieu de passer par des labels + goto + macro (cocktail explosif si utilisé sans parcimonie).

Code

int fonction() {
    ...
    if(!machin())
        gestionErreur(1, fichier, buffer);
    if(!machin2())
        gestionErreur(2, NULL, buffer);
    if(!machin3())
        gestionErreur(1, fichier, buffer);
    ...
}

int gestionErreur(int errno, void *fichier, void *buffer) {
    switch(errno) {
        case 0: ...
        case 1: fclose (fichier);
        case 2: free(buffer); break;
        default: ...
    }
}

Bon, d'accord, t'as des variables à passer en plus, mais c'est beaucoup plus portable pour réutiliser le code sur un langage qui n'ai pas de goto, de label ou de macro. Qu'en pensez-vous?

[hubeert]

coucou
personnellement et afin d'optimiser le code je suis pour l'utilisation du binaire autant que possible..
exemple un profil d'utilisateur défini par 32 paramètre qui sont sur on ou off. dans une base de donnée normale ou avec des variables nous avons besoin de 32 champs ou variables différentes. si nous avons 1 000 000 d'utilisateurs nous avons donc 1 million d'enregistrement pour 32 champ mais si on utilise la programmation binaire avec les opérateurs adéquat on peut stocker 32 paramètre dans un seul nombre..lorsque on veut transférer un profil on manipule un seul chiffre. dans un jeu de tetris par exemple pour savoir ou se trouve les éléments je n'ai a tester qu'une dizaine de chiffre.. dans un panneau lumineux régit par des diiodes mes lettres sont représentées par un carre de 30 diodes que j'allume ou jeteinds pour faire un A un I ou un Z chaque lettre est représentée par un nombre en binaire qui indique quelle diode est éclairée ou éteinte; avec 26 variable (26 nombres) par exemple j'ai mon alphabet..

[noop]

coucou
personnellement et afin d'optimiser le code je suis pour l'utilisation du binaire autant que possible..
exemple un profil d'utilisateur défini par 32 paramètre qui sont sur on ou off. dans une base de donnée normale ou avec des variables nous avons besoin de 32 champs ou variables différentes. si nous avons 1 000 000 d'utilisateurs nous avons donc 1 million d'enregistrement pour 32 champ mais si on utilise la programmation binaire avec les opérateurs adéquat on peut stocker 32 paramètre dans un seul nombre..lorsque on veut transférer un profil on manipule un seul chiffre. dans un jeu de tetris par exemple pour savoir ou se trouve les éléments je n'ai a tester qu'une dizaine de chiffre.. dans un panneau lumineux régit par des diiodes mes lettres sont représentées par un carre de 30 diodes que j'allume ou jeteinds pour faire un A un I ou un Z chaque lettre est représentée par un nombre en binaire qui indique quelle diode est éclairée ou éteinte; avec 26 variable (26 nombres) par exemple j'ai mon alphabet..

Méfie toi, le binaire n'est pas la donnée la plus optimisée pour les bases de données. J'ai eu récemment a envisager cette solution dans le cadre d'une application qui avait une désynchronisation de base de données entre deux logiciels. Bref, afin de marquer les champs mis à jour j'avais envisager une utilisation de flags avec du binaire. renseignement pris, un admin Oracle m'a déconseiller fortemment cette astuce. J'ai suivi à la lettre ce conseil.

Etant donné la puissance des processeurs et les capacités de stockage, les économies de bout de chandelle peuvent être catastrophiques.

[hubeert]

coucou;
je n'ai pas parlé "vraiment" de base de données mais de variables constituées d'un seul nombre et pouvant contenir 32 indications on ou off..
ceci dit l'optimisation relève souvent de toute petites économies
et je suis totalement contre l'idée que puisque les processeur sont performants et puisque on a de la place on peut coder comme un cochon (je sais que ce n'est pas ça que tu as voulu dire ) et ne pas rechercher une manière plus optimisée.. mais je pense aussi que les codeurs professionnels n'ont pas toujours le temps au vu du cahier des charges.

Ce message a été modifié par hubeert - 17 Aug 2009, 09:04.

[noop]

coucou;
je n'ai pas parlé "vraiment" de base de données mais de variables constituées d'un seul nombre et pouvant contenir 32 indications on ou off..
ceci dit l'optimisation relève souvent de toute petites économies
et je suis totalement contre l'idée que puisque les processeur sont performants et puisque on a de la place on peut coder comme un cochon (je sais que ce n'est pas ça que tu as voulu dire ) et ne pas rechercher une manière plus optimisée.. mais je pense aussi que les codeurs professionnels n'ont pas toujours le temps au vu du cahier des charges.

1) concernant les 32 indications ON/OFF. Certes autant pour moi concernant les bases de données. Mais l'utilisation du binaire limite beaucoup les évolutions du code. Comment fais tu pour traiter la 33 ème ? . Bon je pinaille..... mais quelque fois en cours d'évolution d'un projet, le domaine de valeurs d'un indicateur peut quelque fois passé du ON/OFF a ON/OFF/INDETERMINE....là je ne sais pas comment tu fais evoluer ton traitement sauf a faire une belle verrue

2) l'optimisation coûte souvent très cher et doit rester dans un ratio qui ne grève pas les coûts de maintenance ( la maintenance = 70% de la charge d'un soft). Et avant d'en arriver au binaire, les gains de performances peuvent être trouvés sur des motif de programmation simples: examen des boucles internes, recherche dans les chaines de caractères, utilisation de pattern plutot que de boucle laborieuses.

3) le travail de cochon.....ca c'est dans l'air du temps et c'est une tendance qui va devenir la règle (si ce n'est pas déjà fait).

[hubeert]

pour le 33eme tu crées une deuxième variable voire 3 ou 4. mais déjà 31 ca fait un paquet d'indication in fine !!
je comprend pas pourquoi ça limiterai l'evolution du code?
indéterminé n'est qu'une variante de on et off tu peux accoler la possibilité a cote sur le bit voisin par exemple
alors je ne men suis servi que pour pour des jeux ou j'ai besoin de savoir ou se trouve un élément je men suis servi par exemple dans le tetris que j'ai dans ma signature a la fois pour le jeux lui même mais aussi pour créer des forme bizarres en 2 seconds je peux créer n'importe quelle forme et l'inclure dans le jeux sans reprendre tout le code comme c'est fait dans un tetris traditionnel (d'ailleurs tu trouveras pas de tetris avec des formes non traditionnelle ' enfin jen ai pas trouve lol)
je m'en suis servi aussi dans une jeu de croix et l'inteligence artificielle !! mais mon programme est trop fort il est quasiment imbattable.. lol
ais encore dans plein de truc inutile comme un jeu de cascade
cascade
il sagit de faire degringoler des casse de même couleurs qui se touchent
et sans le binaire au lieu de 60 ligne de code j'en aurais je sais pas combien avec des ralentissements incroyables..
ca peut servir aussi pour dans un jeu "remplacer" le concept de tile
enfin bref a plein de chose; il est même étonnant que le concept soit si peu utilisé meme de la part de codeurs chevronnés mais il est clair qu'ils ont pas forcément le temps de s'amuser lorsqu'ils bossent

[noop]

je men suis servi par exemple dans le tetris que j'ai dans ma signature a la fois pour le jeux lui même mais aussi pour créer des forme bizarres en 2 seconds je peux créer n'importe quelle forme et l'inclure dans le jeux sans reprendre tout le code comme c'est fait dans un tetris traditionnel (d'ailleurs tu trouveras pas de tetris avec des formes non traditionnelle ' enfin jen ai pas trouve lol)

Effectivement, dans certains domaines (jeux, IA), les chaînes de bits servent beaucoup. Il y a même par le passé un moteur de système expert qui était implémenté sur l'utilisation de masque binaires. Dans mon cas, j'ai rarement développé des tetris pour mes clients Dommage car ce serais plus fun que certains cahiers de spécifications abscons

[Jaypee]

Je suis du même avis que noop, et je rajouterai "montre-moi tes tests de performances et mesure-moi le gain effectif".

Le codeur doit avoir une vision suffisamment large pour ne pas provoquer de mauvaises performances comme des requêtes qui provoquent des balayages de table sur des champs non-indexés, ou (je l'avoue, je l'ai fait) faire de la lecture sequentielle sur les logs à la recherche d'infos passées (j'ai honte !)... Donc c'est plus le comportement qu'il faut améliorer.

Tout à fait d'accord pour la maintenance. Maintenant si tu cherches à protéger ton job... c'est une autre discussion.

J-P

Ce message a été modifié par Jaypee - 17 Aug 2009, 12:46.

[noop]

Tout à fait d'accord pour la maintenance. Maintenant si tu cherches à protéger ton job... c'est une autre discussion.

Très juste. On peut même renommer le topic: "Techniques et astuces de programmation pour garder son job"

[hubeert]

coucou..
c'est pas mon job. j'ai un videoclub et je fais aussi des pizzas c'est un loisir. j'ai programmé un truc pour Schlum et Ghisdiem en binaire on pouvait sans doute le faire autrement je voulais juste apporter une petite idée si cela tourne a celui qui code le mieux et qui a raison.. ca ne sert a rien et dans le logiciel usité les gains de performance sont .... top et bienvenues aux idées toutefois et longue vie a ce topic amitié a tous ceux dont c'est le métier.. et qui n'ont pas forcement le temps de faire des jeux ..

Ce message a été modifié par hubeert - 17 Aug 2009, 20:02.

[noop]

On plaisante..... Et puis l'histoire du mec qui code comme un saguoin dans le milieu professionnel celà existe (ce qui n'est pas ton cas car toi tu fais ca pour le plaisir). Moi j'en ai connu un qui était dans le même bureau que moi il y a presque 30 ans, il refusait de m'expliquer ce qu'il avait codé en RPG alors que je devais traduire son programme en COBOL. Et bien son boulot il se l'est gardé jusqu'à la retraite....et je ne lui jette pas la pierre car maintenant je suis un peu dans sa situation. Par contre je ne fous pas les collègues dans la mouise. Mes programmes / scripts sont tous documentés.

[hubeert]

coucou
d'accord alors continuons sur les astuces et les techniques bonne continuation a tous

Ce message a été modifié par hubeert - 17 Aug 2009, 14:06.

[Hellstorm]

On plaisante..... Et puis l'histoire du mec qui code comme un saguoin dans le milieu professionnel celà existe (ce qui n'est pas ton cas car toi tu fais ca pour le plaisir). Moi j'en ai connu un qui était dans le même bureau que moi il y a presque 30 ans, il refusait de m'expliquer ce qu'il avait codé en RPG alors que je devais traduire son programme en COBOL. Et bien son boulot il se l'est gardé jusqu'à la retraite....et je ne lui jette pas la pierre car maintenant je suis un peu dans sa situation. Par contre je ne fous pas les collègues dans la mouise. Mes programmes / scripts sont tous documentés.

Entièrement d'accord, y a encore pas logntemps j'ai vu quelque chose d'assez mémorable :

On cast une string en double qu'on recast en string pour recaster en double et finalement recaster en string.

Très performant

[macuserfr]

Le binaire c'est un peu comme l'assembleur. Cela peu booster considérablement les performances mais faut l'utiliser avec parcimonie car

1) Cela prend plus de temps à coder que de rester en haut niveau (coût)
2) Cela est beaucoup moins lisible (maintenabilité)

Je ne sais pas vous, mais je code d'abord "pour que ça marche" (en évitant de faire un code trop crade), ensuite je repasse pour réorganiser (découper en fonctions, mieux commenter). C'est qu'à ce stade là que je vais chercher à optimiser le code, si besoin. Sachant que le processus d'optimisation peut être long et couteux (le temps c'est de l argent, si on est en milieu pro) on préfère souvent (c'est malheureux et paradoxal) acheter du matériel plus puissant que de gagner du temps de traitement sur le code. Cela revient moins cher.

[flocharal]

cascade

J'adore ce jeux, je m'amuse comme un petit fou, ......... en plus les couleurs sont trop chouettes

[Jaypee]

Retour aux trucs...

J'ai un mini-poster imprimé avec les commandes de "Vi". C'est un collector échappé des années 80, et je n' ai même plus le postscript original...

Tout ça pour dire qu'il rappelle des commandes essentielles comme "Afficher les numéros de lignes". Perso, je ne savais même pas que "Vi" savait faire ça

:se nu

pour seT nuMBER

Parlant d'éditeurs, mon estime pour TextWrangler est remontée en flèche, après que j' ai eu à re-architecturer un fichier XML. Je devais passer d'un schéma avec des attributs à un schéma avec des sous-éléments.

TextWrangler a un mode un peu simplistement nommé "use grep".

La chaîne de départ, <element attr1="val1" attr2="val2"/>

et la chaîne souhaitée:
<element>
<attr1>val1</attr1>
<attr2>val2</attr2>
</element>

Avec TW, on va chercher
<element attr1="(.*)" attr2="(.*)"/>

Rappelez-vous: Dans les expressions régulières, les parenthèses c'est un peu comme des mémoires d'une calculette et on rappelle la valeur avec \1 ou \2

On va le remplacer par:
<element>\r\t<attr1>\1</attr1>\r\t<attr2>\2</attr2>\r</element>


Voilà, deux trucs pour tout public (de bidouilleur quand même)
J-P

Ce message a été modifié par Jaypee - 19 Aug 2009, 20:49.

[noop]

Avec TW, on va chercher
<element attr1="(.*)" attr2="(.*)"/>

Rappelez-vous: Dans les expressions régulières, les parenthèses c'est un peu comme des mémoires d'une calculette et on rappelle la valeur avec \1 ou \2

On va le remplacer par:
<element>\r\t<attr1>\1</attr1>\r\t<attr2>\2</attr2>\r</element>

C'est le même boulot que je faisais depuis 3 jours (mais sous linux en shell). Par contre j'utilise sed. Seule différence, les expressions sont délimitées par \( et \)

[Jaypee]

Je réactive un peu ce bon sujet.

Dernièrement, sur un serveur HP-UX, je lance un script shell préparé avec un des bons éditeurs à la Smultron du PC (NotePad++ en est un) et catastrophe, le script crashe sur la ligne 1 en accusant le fameux BOM UTF-8 (byte order marker, 3 caractères servant d'indicateur pour la polarité des mots machine, l'endianness) invisible dans l'éditeur, on ne peut pas l'éditer.

Par un ami, Google, j'ai découvert la commande vi qui règle ça :
: set noboum
: wq # On resauve

C'est facile à retenir après un crash...
Niveau : Confirmé, quand même
J-P
PS : Apparemment, la commande est inconnue sur vim

Ce message a été modifié par Jaypee - 19 Oct 2009, 08:31.

[noop]

Je réactive un peu ce bon sujet.

Dernièrement, sur un serveur HP-UX, je lance un script shell préparé avec un des bons éditeurs à la Smultron du PC (NotePad++ en est un) et catastrophe, le script crashe sur la ligne 1 en accusant le fameux BOM UTF-8 (byte order marker, 3 caractères servant d'indicateur pour la polarité des mots machine, l'endianness) invisible dans l'éditeur, on ne peut pas l'éditer.

Par un ami, Google, j'ai découvert la commande vi qui règle ça :
: set noboum
: wq # On resauve

C'est facile à retenir après un crash...
Niveau : Confirmé, quand même
J-P

Bonjour,

je bosse aussi sur HP-UX ( ) comment ce caractère a t'il été inséré dans ton script ? Par Notepad++ ? J'ai jamais vu ca !

Ce message a été modifié par noop - 19 Oct 2009, 08:32.

[Jaypee]

Oui un éditeur classique, réglé en UTF-8 avec BOM.

En fait je me suis planté sur la commande vi, ça collait pas. Là où j' ai besoin de scripts shell, ce sont des serveurs Linux, pas sur les serveurs HP-UX qui ont un autre usage...

Mais c'est proche et ça marche bien sous vim :

: set nobomb
: wq

J-P

Ce message a été modifié par Jaypee - 19 Oct 2009, 08:45.

[noop]

Ca y est j'ai vu l'option UTS-8 with BOM. En fait je ne l'avais jamais utilisé ? Ca sert dans quel cas ?

[schlum]

En C/Objective-C je mets toujours cette petite macro pour faciliter le traitement des erreurs:

Code

#define Fail(erreur,label) {if(erreur) goto label;}

oui, je sais, les goto c'est crade, mais c'est pour la bonne cause
Ça permet de regrouper le code de gestion d'erreur en fin de fonction, et ça s'utilise comme ça:

Code

int err;
...
err = appel_de_fonction ();
Fail (err, stop);
...
return;
stop:
NSLog (@"erreur: %d", err);
...

Beauh !
Et les NSException et @try @catch, c'est fait pour quoi ?
(oui, j'arrive après la guerre…)

[Jaypee]

Le BOM ce sont 3 octets conventionnels, qui servent si on échange le fichier UTF-8 entre machines d'architectures différentes, à définir l'ordre des octets dans un mot, big ou little endian. En général, on ne le met pas, mais certains éditeurs n'ont qu'un seul réglage UTF-8, sans précision.

Dans mon cas, le fichier était déjà déployé à destination, donc pour régler juste un encodage, c'eut été un peu pénible de re-déployer. Donc, le patch rapide sur place, suivi de la correction dans le code versionné, pour un prochain kit, était acceptable.

J-P

[cbrandt]

En C/Objective-C je mets toujours cette petite macro pour faciliter le traitement des erreurs:

Code

#define Fail(erreur,label) {if(erreur) goto label;}

oui, je sais, les goto c'est crade, mais c'est pour la bonne cause
Ça permet de regrouper le code de gestion d'erreur en fin de fonction, et ça s'utilise comme ça:

Code

int err;
...
err = appel_de_fonction ();
Fail (err, stop);
...
return;
stop:
NSLog (@"erreur: %d", err);
...

Beauh !
Et les NSException et @try @catch, c'est fait pour quoi ?
(oui, j'arrive après la guerre…)

oui, bon… c'est vrai…
mais j'ai pris l'habitude, car j'ai commencé à mettre ça dans ma "toollib" perso qui marche sous MacOS, Windows et Linux… pour quand je fais du code serveur (portable) sans interface utilisateur…

[Jaypee]

A Schlum, pas grave... il faut aussi signaler le @finally.

On y passe tout le temps, exception où pas.

C'est important pour faire le ménage après une exception. Certaines ressources système manquantes peuvent conduire au besoin de reboot d'un système si on ne les libère pas correctement : threads, file handles... Même en cas d' exception qui va immanquablement conduire à un crash, il faut faire ce ménage avant de s'écraser avec grâce.

J-P

Ce message a été modifié par Jaypee - 19 Oct 2009, 10:50.

[schlum]

oui, bon… c'est vrai…
mais j'ai pris l'habitude, car j'ai commencé à mettre ça dans ma "toollib" perso qui marche sous MacOS, Windows et Linux… pour quand je fais du code serveur (portable) sans interface utilisateur…

Ah oui… Si c'est multi-plateformes, je préfère le C++ avec le même mécanisme d'exceptions (mieux encore que celui d'Objective-C d'ailleurs).

Code

#define TRY try {

#define CATCH \
} catch (MyException &e) { \
    // Log \
    throw; \
}

#define CATCHIGN \
} catch (MyException &e) { \
    // Log \
}

#define THROW(msg) { \
    // Log \
    MyException newE; \
    throw newE; \
}

Et mettre des TRY … CATCH autour de chaque fonction / méthode

A Schlum, pas grave... il faut aussi signaler le @finally.

On y passe tout le temps, exception où pas.

C'est important pour faire le ménage après une exception. Certaines ressources système manquantes peuvent conduire au besoin de reboot d'un système si on ne les libère pas correctement : threads, file handles... Même en cas d' exception qui va immanquablement conduire à un crash, il faut faire ce ménage avant de s'écraser avec grâce.

J-P

Oui… Mais ne pas oublier que le NSAutoreleasePool en Obj-C est automatiquement nettoyé quand on saute avec une exception… même s'il n'est pas libéré dans le @finally
Donc il est plus facile de l'utiliser et de se passer de @finally quand c'est possible

[No6]

" Si on ne peut pas comprendre l'utilité d'un programme en lisant uniquement les commentaires, alors vous pouvez jeter l'ensemble du code ! "

Oui, je suis vraiment d'accord.
J'ajouterai simplement un petit plus, les commentaires doivent aussi apporter une petite touche d'humour et de légèreté si possible.
Il faut aussi penser à l'individu qui les relira dans X années, certainement stressé, dépressif...
La programmation n'attire que trop souvent les individus dans un monde Kafkaïen...

J'ai découvert cette méthode dans les sources de Bill Atkinson et de Scott Knaster ; alors excusez du peu
C'est une bonne pratique (hélas) plutôt rare en France ; qui mériterai d'être diffusée, et à utiliser avec modération, bien sur.

Pourquoi faire du goto et des labels quand un

Code

if(!fonction())
{
    //traitement de l'erreur

Beurk !!!!

Ça me rappelle le temps ou je faisais du débugging sur des programmes en APL.

Et pour le sujet de l'utilisation de tables binaires, je conseille l'analyse des sources de Agrep http://www.tgries.de/agrep/

D'ailleurs, pour apprendre à bien programmer, rien de tel que lire des codes sources, prestigieux ou non, comme Agrep

Ah, j'oubliais, à placer dans le chapitre "bonne pratiques" quand vous tapez une accolade (ou une parenthèse, crochet) ouvrante, taper immédiatement la fermante correspondante, puis utilisez le retour arrière pour écrire le contenu...

[noop]

Ah, j'oubliais, à placer dans le chapitre "bonne pratiques" quand vous tapez une accolade (ou une parenthèse, crochet) ouvrante, taper immédiatement la fermante correspondante, puis utilisez le retour arrière pour écrire le contenu...

Très juste. Même combat pour les caractères suivants:

Code

' " `[ (

je viens d'en faire l'expérience dans un script shell (oublié un " fermant). Même chose quand on utilise les caractères de control par exemple pour taper:

Code

"......\"Voici une belle chaîne de char quotée\" ....."

Eh bien je tapes tout de suite une chaîne quotée NULL [\"\"] et je rentre mon texte dedans.

[Jaypee]

Toujours à Schlum et à propos du @finally, je faisais allusion à tout ce qui n' est pas mémoire, et que l'on consomme comme ressource. Imaginons un Thread zombie qui "tient" une connexion de database. Si on a un bug qui fait ça, on relance l'appli, ça marche un moment... puis ça crashe, on essaie de nouveau... et à chaque tentative, on aggrave le problème en saturant le système (plus de threads) ou en consommant tout le connection pool... Au bout d'un moment, le reboot est inévitable.

Bon, c'est vrai, j' ai une culture de serveur et de règlement à la con (faut de la paperasse pour rebooter un serveur de prod , voire de développement qui peut aussi être partagé) , qui me donnent la hantise du reboot. Sur un PC ou un Mac, ce n' est pas si grave.

@No6 : En APL, tu fais allusion au branch vers expression ?
-> expr

C'est un GOTO calculé comme en Fortran, mais un -> (chaine vide ou vecteur nul ou tout objet de dimension 0) est un saut à la ligne suivante, et -> 0 est équivalent à un return
Certains créaient une fonction IF pour faire plus propre :
-> etiquette IF cond

J-P

Ce message a été modifié par Jaypee - 19 Oct 2009, 15:27.

[schlum]

Jaypee, en langage objet, je règle ce problème avec les constructeurs pour tout ce qui est initialisation (allocation, connexion, ouverture de "handles" ou sockets etc.) et les destructeurs pour tout ce qui est finalisation (déallocation, déconnexions, fermeture de "handles" ou sockets etc.)
Du coup, tout mon nettoyage se passe à coup d'alloc et de release.
En C++ c'est encore plus pratique car j'utilise au maximum des variables sur la pile, donc libérées automatiquement dès qu'on sort du scope, et ce quelque soit la sortie (exception, goto, sortie normale…). Et on peut même créer un scope pour l'occasion à coup d'accolades.

[Jaypee]

Au temps pour moi, en culture Java, je ne fréquente pas les destructeurs... toute une éducation à refaire...

Tout dépend quand même si le destructeur de l'objet est bien écrit, c'est à dire si la désallocation d'un File handle (le free de la structure File Handle en mémoire) est précédée de son changement d'état (le "close")

Mais OK, c'est vu...
J-P

[schlum]

Ah oui, bien sûr, il faut que tout soit propre au niveau libération… Ça fonctionne également avec les mutex que j'ai oublié dans mon énumération (ne pas déverrouiller un mutex est une des pires choses qui peuvent arriver…).