Discussion :

[moldavi]

Bonjour.

un bon principe à mon avis est que pour tout block (section de code, fonction boucle etc.) un seul point d'entrée et un seul point de sortie

et mon propos est que des docteurs es science informatique on étudié toute un tas de cas types et on pondus de bonnes pratique pour les réaliser quelque soit le langage.

J'utilise très souvent le break pour une sortie de boucle.

Dans votre explication, vous ne donnez pas la raison pour laquelle le design pattern "tant que non fin et non trouvé faire" est un bon principe par rapport au break. D'ailleurs vous ne dîtes pas que le break est un mauvais principe.

Pouvez-vous nous donner plus de détails sur ce fait, merci.

[atha2]

Pour ma part mon seul secret de programmation est d'essayer de coder le plus simple possible. Si possible en lisant mon algo à haute voix, j'essaye que ce soit le plus proche possible du français (où anglais selon les projets). Cela permet de ne pas se prendre la tête quand je relis le code plus tard.

un bon principe à mon avis est que pour tout block (section de code, fonction boucle etc.) un seul point d'entrée et un seul point de sortie

et mon propos est que des docteurs es science informatique on étudié toute un tas de cas types et on pondus de bonnes pratique pour les réaliser quelque soit le langage.

J'imagine que vous êtes aussi de ceux qui ne mettent qu'une seul instruction return par fonction. Votre arguments n'est pas cependant très pertinent (mais je respect votre choix), ces bonnes pratiques sont définies pour tout les langages, cela veut donc dire qu'elles se basent sur un sous ensemble commun (return et break n'existe pas dans tout les langages) à tout les langages. Je trouve dommage de devoir se passer des spécificités des langages. Je les vois plus comme une possibilité (dans le cas du break et du return) d'améliorer la lisibilité du code.

[Atatorus]

je n'ai pas dit que break est un goto. J'ai dis que je n'aime ni l'un ni l'autre

Le break et son cousin le continue rendent pourtant de bons services : si la condition du break est en début de boucle, ils évitent un test supplémentaire dans le corps de la boucle.

un bon principe à mon avis est que pour tout block (section de code, fonction boucle etc.) un seul point d'entrée et un seul point de sortie

Ceci se justifie tout à fait dans une fonction qui doit utiliser une ressource puis la libérer avant de sortir. Avoir plusieurs points de sortie multiplie les chances d'oublier sa libération. Et encore, même dans ce cas j'ai 2 points de sortie : si au début de ma fonction on n'obtient pas ma ressource, pas la peine d'aller plus loin.
Quand aux autres cas, sortir de la fonction à plusieurs endroits ne pose aucun problème. Ça peut même améliorer la lisibilité du code.

[moldavi]

Re.

et mon propos est que des docteurs es science informatique on étudié toute un tas de cas types et on pondus de bonnes pratique pour les réaliser quelque soit le langage.

Il est vrai que de connaître les bonnes pratiques est intéressant. Mais au-delà, je pense que le plus intéressant est le pourquoi de ces bonnes pratiques.

Ils disent juste, rendez votre programme le moins complexe possible. Un seul point d'entrée et un seul point de sortie, les choses sont plus simples et on évite les embrouilles. Et ils ont raison.

Malheureusement ce sont juste de bonnes pratiques, et la pratique ne rejoint pas toujours la théorie.

Un exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
void MethodeAvecBreak(){

  unsigned __int64 i64Test = 9999999999;

  for(unsigned __int64  i64 = 0; i64 < 10000000000; i64++){

    if(i64 == i64Test)
     break;
  }
}

void MethodeBonnePratique(){

  unsigned __int64 i64Test = 9999999999;
  unsigned __int64 i64 = 0;
  bool bNotFound = true;

  while(bNotFound && i64 < 10000000000){

    if(i64 == i64Test)
      bNotFound = false;

    i64++;
  }												}

Petit Bench, la méthode bonne pratique est plus lente, puisque dans la boucle on effectue un test supplémentaire.

J'ai fait express de faire une boucle énorme, il y a deux à quatre secondes d'écart, mais je pense que dans le développement de jeu vidéo, on va éviter les bonnes pratiques, du moins celle-ci.

[el_slapper]

Pas vraiment un secret, mais quand j'ai une spec à peu près complète(ça arrive), j'essaye de faire coller mes paragraphes à la spec le plus près possible. Exemple de spec :

*Pour tous les Bourse France, prendre A1 comme valeur de référence
*Pour tous les Bourse étrangère sauf Honk-Kong, prendre A2
*Pour tous les OPCMV supérieurs à 10000 €uros, prendre A3
*Pour tout le reste, prendre A4

Avec des If imbriqués, ça devient assez vite illisible. en VB6, on peut faire :

Code :

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

1
2
3
4
5
6
7
8
9
10
Select case true
    Case boolBourseFrance
        valeurReference = "A1"
    Case ((boolBourseEtrangere) and (not boolHongKong))
        valeurReference = "A2"
    Case ((boolOPCVM) and (montant > 10000))
        valeurReference = "A3"
    Case else
        valeurReference = "A4"
end select

L'immense avantage, c'est que si un nouveau reprend la spec, et rajoute une ligne dans le tableau d'exigences, et qu'un nouveau reprend le code, y'a pas besoin de comprendre. Bon, je fais ça plus en cobol avec des EVALUATE, mais c'est sans doute hostile pour 99% des lecteurs.....

[sekaijin]

He ho on se calme

je n'ai jamais prétendu détenir une vérité absolue
le sujet est ce que nous faisons
chacun d'entre nous

je dis JE FAIS c'est tout Je ne dis pas ON DOIT
je dis que je Préfère faire

Code :

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

1
2
3
4
5
6
7
8
9
function foo() {
  if (r = test()) then {
     ...
     returnValue = ...;
  } else {
     returnValue = false;
  }
  retrun retrunValue;
}

que

Code :

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

1
2
3
4
5
6
function foo() {
  if (! r = test()) then 
  retrun false;
  ...
  return ...;
}

c'est un choix qui a des avantage et des inconvénients.
c'est un choix comme un autre

A+JYT

[Benjamin Delespierre]

J'ai oublié ça :

Cela découle d'une mauvaise compréhension. Chaque fois qu'une page est chargée (notamment après un submit) c'est une nouvelle exécution d'un programme qui a lieu.
Hors dans n'importe quel autre contexte on ne s'étonne pas que d'une exécution à l'autre d'un programme les données ne soient pas conservées si on n'a pas pris soin de les sauver dans un truc persistant.

Je me suis posé la question il n'y a pas longtemps: serait-il possible de contourner ce problème en utilisant des pools d'objets persistés sur la variable de session ?

Par exemple; j'utilise fréquemment des objets Active Record (fais maison) pour ma couche modèle. Leur problème principal est le coût d'instanciation en temps car à chaque fois que le contexte de l'application est recréé (en fait à chaque changement de page) il faut, pour une bonne partie de ces instance détruites, les instancier à nouveau et les nourrir avec des résultats SQL.

On pourrait à cet effet se servir d'un registre dans lequel les objets seraient stockés lors de leur instanciation. Cela impose notamment de passer toutes les instanciations par une factory d'objet capable de les récupérer du registre ou de les créer s'il n'y sont pas car $this = MonRegistre::get(<un_token>); est bien évidement impossible dans un constructeur.

Je viens de faire un prototype qui pourrait aider, ce sera le sujet d'un autre topic voire d'un article (bien que je n'en ai jamais écris pour ce developpez.net).

(Dès que j'ai fini la rédaction de mon topic, je mets le lien ici)

[moldavi]

Bonjour sekaijin.

He ho on se calme

Je pense que nous sommes calmes et qu'il n'y a pas eu d'agression. Personnellement ce que tu as dit m'a intéressé et je t'ai demandé des précisions. Ensuite j'ai juste argumenté sur le concept. C'était de la curiosité de ma part, pas une agression.

Cordialement.

[Luc Hermitte]

Il est vrai que de connaître les bonnes pratiques est intéressant. Mais au-delà, je pense que le plus intéressant est le pourquoi de ces bonnes pratiques.

Ils disent juste, rendez votre programme le moins complexe possible. Un seul point d'entrée et un seul point de sortie, les choses sont plus simples et on évite les embrouilles. Et ils ont raison.

Ces bonnes pratiques ont un contexte.
Je vous invite à chercher SEME et SESE (puisque c'est de cela dont on parle) sur les forums.

Ici, le contexte d'apparition, ce sont les langages sans exceptions[*], ni aucun moyen déterministe de collecter les ressources acquises (mutex, mémoire, socket, fichier, pots de peintures, etc).
Les gens préférant faire des fonctions à rallonge plutôt que de se donner des bonnes pratiques, on a convergé vers une situation batarde qui a consister à "interdire" ce que le moins de personnes utilisait : des ruptures du flot de d'exécution. Le pire, c'est que nous sommes à des parsecs des gotos du célèbre Goto considered harmful vu que les tags de saut sont très restreints : extrémité de boucles et sortie de fonction.

Avec l'arrivé des exceptions, on réintroduit les ruptures du flot. Et pourtant tout ceux qui critiquent les ersatz du SEME (return, break, continue, redo/again (? ou un truc du genre en Perl)) oublient que les exceptions appartiennent à la vile engeance qu'ils critiquent ...
[*] et que dire de modula-3, sorte de successeur de Pascal pourtant, qui dispose de moyens de rompre le flot d'exécution? De la lecture intéressante par là aussi: http://www.gdzid.com/LivreIntro.html#errata (mais n'oubliez pas de chercher dans les archives du site, hein? -> SESE, SEME)

[peufeu]

Ici, le contexte d'apparition, ce sont les langages sans exceptions[*], ni aucun moyen déterministe de collecter les ressources acquises (mutex, mémoire, socket, fichier, pots de peintures, etc).

Hé oui, je trouve cela fort amusant que la meilleure façon de nettoyer proprement derrière soi en C soit ... le fameux goto.

[D4rkTiger]

Bonjour,

Je voudrais dire que les exemples qui ont été donnés au début de ce sondage par la rédaction sont utiles aussi bien dans le DEBUG que dans le code. Un code simplifié n'est pas un code illisible.

C'est justement parce que beaucoup de personnes ignorent ces simplifications de code que beaucoup les trouvent illisibles ou dur à comprendre à leur lecture mais en fait elles ne le sont pas plus que d'autres.

Les langages d'aujoud'hui ont bien servi à simplifié l'assembleur non ? Pourtant l'assembleur pour les développeurs de l'époque était lisible. Pas pratique mais lisible quand même. Il suffit juste de savoir ce que cela veut dire.

Et je souhaiterai également dire que les simplifications de code ne sont utiles dans un projet que si le projet est commenté car justement dans le cas où le projet est repris il est bon de toujours laissé un exemple en commentaire afin que les personnes qui reprennent et qui ne sauraient pas comment ça marche puisse comprendre la chose. Cela fait ainsi du partage de connaissance et agrandit la culture de chacun.

Et puis on ne le rappellera jamais assez, dans des choses que l'on ne comprend pas, il y a le fidèle ami du développeur "Google"

[sekaijin]

il y a simplification et simplification

j'ai trouvé un prog dont 50% du source se déroulait dans le test de fin de boucle d'un for genre

Code :

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

1
2
3
4
5
for (i=0; ICI 
plusieurs centaines de lignes de codes
, i++) {
...
}

heu un appel de fonction avec un nom clair c'est tout de même plus lisible
et ça coût un appel de fonction (au pire en c++ on met un inline)

à l'opposé j'ai aussi vu des source qui était très structuré sur le nomage la façon de faire des boucle des fi indenté commenté et tout le reste et dont les algos étaient tellement alambiqués que ça devenait incompréhensible.

à tel point qu'en réécrivant 10% du code et en restant très verbeux dans mon écriture j'ai divisé par six le temps d'exécution et pour certaine fonctionnalité pat 9 la taille du code exécuté.

donc comme toujours expliquons ce que nous faisons
A+JYT

[doublex]

Une astuce que j'apprécie pour la maintenance et l'évolution du code, c'est de mettre un commentaire/pavé avant chaque méthode importante, qui explique succinctement ce que fait ladite méthode.
Cela évite d'avoir à relire toute la méthode pour un autre programmeur (ou pour soi-même si on l'a écrite il y a quelque temps)

/************************************************************************************
*La méthode foobar permet de..... ************************************************************************************/

public void foobar() {
// code de la méthode foobar
}

[sekaijin]

Une astuce que j'apprécie pour la maintenance et l'évolution du code, c'est de mettre un commentaire/pavé avant chaque méthode importante, qui explique succinctement ce que fait ladite méthode.
Cela évite d'avoir à relire toute la méthode pour un autre programmeur (ou pour soi-même si on l'a écrite il y a quelque temps)

/************************************************************************************
*La méthode foobar permet de..... ************************************************************************************/

public void foobar() {
// code de la méthode foobar
}

Dans ce cas là utilise les commentaire javadoc (quelque soit le langage)

Code javascript :

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

1
2
3
4
5
6
7
8
9
10
    /**
     * Used for un-phantoming a record after a successful database insert.  Sets the records pk along with new data from server.
     * You <b>must</b> return at least the database pk using the idProperty defined in your DataReader configuration.  The incoming
     * data from server will be merged with the data in the local record.
     * In addition, you <b>must</b> return record-data from the server in the same order received.
     * Will perform a commit as well, un-marking dirty-fields.  Store's "update" event will be suppressed.
     * @param {Record/Record[]} record The phantom record to be realized.
     * @param {Object/Object[]} data The new record data to apply.  Must include the primary-key from database defined in idProperty field.
     */
    realize: function(rs, data){

cela te permet de générer une doc de ton projet.
certain IDE les utilise pour t'aider dans la rédaction de ton code en te proposant de l'aide basé dessus
pour les langage non typé les outils permettant de créer des webservices par exemple les utilises pour faire correspondre les type webservice avec tes méthodes et données.
bref que des avantage à "normaliser" ce genre de bloc
A+JYT

[Barsy]

+1 pour la javadoc.

L'avantage de cette méthode, c'est que beaucoup d'IDE l'intègre dans l'intellisense et ça évite d'avoir à farfouiller dans son code pour se rappeller l'utilité de chaque fonction.

[Erwy]

bon je sais qu'un langage comme XSLT n'intéresse personne mais bon c'est le seul que je maîtrise assez pour connaitre ces "trucs".

Donc en XSLT, le "truc" des fan boys (on n'est pas très nombreux ) du langage c'est xsl:key.

C'est une fonction qui associe un noeud à une valeur (la sienne , celle de son frère, une concaténation des deux , une valeur fixe enfin n'importe quoi) et qui permet d'accéder directement à ce noeud sans recherche dans le XML.
C'est un peu l'équivalent d'un index dans un SGBD.Les débutant la connaisse car elle permet de traiter les doublons en XSLT 1.0.

Les algo les plus complexes en XSLT c'est quand la structure du XML n'a pas de réelles correspondance avec de traitement.
En gros quand la structure physique ne correspond pas du tout à la structure de sortie .
On peut, souvent pas toujours, grâce au xsl:key , reconstruire une structure "logique" plus proche de nos désideratas afin d'eviter des algo "usine à gaz".
Mais il faut bien maîtriser les logiques du langage et des parcours des données pour s'amuser à ça

[Flaburgan]

Tu sais s'il est possible de le faire avec Linq to XML ?

[Erwy]

Tu sais s'il est possible de le faire avec Linq to XML ?

Désolé, jamais utilisé, mais honnêtement cela m'étonnerais.

XSLT est un langage "centré sur la donnée" , on peut le comparer au PL/SQL d'Oracle.
Logiquement il est pourvu de mécanisme de traitement spécifique qui n'ont pas de raison d'être dans des environnements plus "généraux"

[B.AF]

Désolé, jamais utilisé, mais honnêtement cela m'étonnerais.

XSLT est un langage "centré sur la donnée" , on peut le comparer au PL/SQL d'Oracle.
Logiquement il est pourvu de mécanisme de traitement spécifique qui n'ont pas de raison d'être dans des environnements plus "généraux"

Aimant les deux, on peut faire des choses similaires en manipulation de données. Mais c'est vrai qu'XSLT est méconnu et sous employé, ça m'a toujours surpris d'ailleurs.

[sekaijin]

XSL-T (du moins les implémentations existantes) est peut adapté au transformation au fil de l'eau. la consommation mémoire est trop lourde.

comment transformer un flux XML de 800 Go ?
Sax permet de le traiter au fil de l'eau mais xslt s'applique plutôt à dom
et Dom monte tout en mémoire.

donc souvent soit les transformations son faites en java ou c en utilisant Sax
soit le flux est injecté dans un base et pl/sql est plus adapté.

Mais xslt reste tout de même un très bon outil. et il est très fortement utilisé dans les SI même si on ne le voie pas toujours.

je pense au EAI en java par exemple qui utilise des composant SCA pour orchestrer les échange entre applications. dans ces outils très souvent sans même que le développeur ne le voit le message est sérialisé (pour l'échange entre composant SCA) et les transformation qu'il doit subir sont en fait en grande partie faite par xsl-t.
généralement l'outil propose un systeme de définition des transformation qui va générer et du xsl-t et des méthode java pour les opération complexe non réalisable par xsl-t
à l'exécution le moteur xsl-t assure la transformation est le cas échéant appelle la méthode java adéquate.

je vois des centaines de cas d'utilisation chaque jour.
A+JYT