+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 7 PremièrePremière 123456 ... DernièreDernière
Affichage des résultats 21 à 40 sur 124
  1. #21
    Membre du Club
    Homme Profil pro
    Inscrit en
    mars 2005
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 12
    Points : 43
    Points
    43

    Par défaut

    ..."write less code"...
    Je ne suis pas tout à fait d'accord avec ce conseil :
    - une code "simple" n'est pas forcement le plus lisible.
    - réutiliser trop de "choses" prises ailleurs, conduit à une perte de la maîtrise de son code.

    Pour moi, le conseil n°1, ça reste quand même :
    ...d'abord rendre son code fonctionnel avant de vouloir l'améliorer !
    J'ai l'habitude de dire à mes jeunes développeurs de :
    1) écrire un code qui fait ce que l'on demande.
    2) écrire un code maintenable, c'est à dire, avant tout, compréhensible par un autre développeur.
    3) optimiser si nécessaire.

  2. #22
    Membre confirmé Avatar de DotCertis
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    janvier 2012
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : janvier 2012
    Messages : 50
    Points : 268
    Points
    268

    Par défaut

    J'ajouterai un truc 'basique" que je n'ai pas vu dans les discussions ni dans l'article : écrire des commentaires. D'abord en début de programme en expliquant de façon succincte le but de programme (avec les inputs et les output) et à l'intérieur en disant ce que je vais faire dans les lignes de code qui suivent et comment.

    Oui c'est basique mais le fait de mettre un commentaire avant d'écrire les lignes de codes qui font ce qui dans le commentaire permet de réfléchir à ce qu'on va faire et oblige à prendre un minimum de recul. Quand à celui du début ça rejoint l'idée de Bill Wagner, en s'obligeant à une réflexion fonctionnelle.

    En plus en cas de problème, plutôt que d'avoir à tout de suite plonger dans le code, en relisant tous les commentaires qu'on a mis on retrouve beaucoup plus facilement l'enchainement qu'on a prévu ce qui permet d'identifier rapidement ce qu'on a pu rater ou une étape qu'on aurait oublié.

    Et puis c'est bien plus simple pour le gentil codeur qui passera plus tard

  3. #23
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    7 085
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 7 085
    Points : 17 792
    Points
    17 792

    Par défaut

    DotCertis -> Les commentaires dans le code est un autre (vaste) débat, régulièrement alimenter ici même

    La dernière discussion en date autour de ce thème --> http://www.developpez.net/forums/d12...entaires-code/
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  4. #24
    Membre actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2006
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Mayenne (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2006
    Messages : 78
    Points : 164
    Points
    164

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    +1, voire +1000

    J'ai 12 ans de bouteille, mais, au final, j'ai toujours plein de limites, et plein de domaines dans lesquels je suis encore débutant. Notre domaine est tellement vaste que nous sommes tous débutants, presque partout. Il y a toujours plys de choses à apprendre que de choses que l'on sait.

    Croire que l'on sait, c'est un des plus gros risques, je crois.
    +1

    Comme le dit le proverbe chinois :
    Celui qui sait qu'il sait, écoute-le.
    Celui qui sait qu'il ne sait pas, éduque-le.
    Celui qui ne sait pas qu'il sait, éveille-le.
    Celui qui ne sait pas qu'il ne sait pas, fuis-le.
    "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." (Code for the Maintainer)
    I usually maintain my own code, so the as-if is true!

  5. #25
    Membre Expert
    Avatar de Voïvode
    Inscrit en
    mars 2007
    Messages
    301
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 301
    Points : 1 798
    Points
    1 798

    Par défaut

    À peine arrivé au milieu de la 2ème page du sujet, on peut déjà lire pas mal de bons conseils.

    La lisibilité est un point important car la programmation est un domaine intellectuellement exigent. Bien programmer consiste avant tout à écrire du code avec soin pour éviter de se compliquer la vie.

    Par exemple :
    • Respecter une convention d'écriture officielle ou non, le but étant d'avoir un style cohérent. Notre cerveau aime avoir ses petites habitudes, un peu de discipline dans la mise en forme rend la lecture moins difficile pour soi-même et pour les autres. Cela commence par des choses aussi banales que l'indentation ou le bon usage des espaces dans une instruction.
    • Bien choisir les noms de ses variables et de ses fonctions. Sans rentrer dans du camelCase vs under_score, un nom doit être en mesure d'évoquer encore quelques choses après un week-end arrosé quelques jours sans travailler sur le code.
    • Documenter un minimum ne serait-ce que pour se repérer plus facilement. N'est-ce pas frustrant de se remettre à un ancien projet et de ne plus savoir à quoi sert cette foutue méthode ? Sans faire du Proust, une simple phrase descriptive peut nous épargner des épisodes décourageants.


    À part ça, il y a aussi jeter un œil sur Developpez.com qui est pas mal.

    Edit : J'adore ta citation Pergos.

  6. #26
    Membre éprouvé
    Avatar de VivienD
    Homme Profil pro
    Ingénieur en génie électrique, électronique et informatique industrielle
    Inscrit en
    octobre 2009
    Messages
    262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Ingénieur en génie électrique, électronique et informatique industrielle
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : octobre 2009
    Messages : 262
    Points : 425
    Points
    425

    Par défaut

    Bien que n'étant pas professionnel, j'utilise quelques principes pour programmer.

    Premièrement, je comprends et définis clairement le problème à résoudre; et sur ce point je rejoins donc YannPeniguel.
    Ensuite, je conçois sur papier mon programme, pour savoir ce que j'ai en entrée et en sortie et comment chaque partie de mon programme doit interagir entre eux et avec l'utilisateur.
    Enfin je pisse mon code tout en restant concis et logique. Au passage, je laisse quelques commentaires pour indiquer les quelques parties qui peuvent être complétées par des fonctions supplémentaires ou pour «scinder» mes fonctions en sous-parties (au cas où je veuille retravailler mon code après une cuite dantesque).

    Euh... sinon... ça veut dire quoi «factoriser un code» ?

  7. #27
    Membre Expert
    Avatar de Gruik
    Développeur Web
    Inscrit en
    juillet 2003
    Messages
    1 563
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juillet 2003
    Messages : 1 563
    Points : 1 676
    Points
    1 676

    Par défaut

    Coder moins et concevoir plus ?

  8. #28
    Membre habitué
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    février 2008
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : février 2008
    Messages : 71
    Points : 114
    Points
    114

    Par défaut

    Le conseil qui m'a le plus marqué quand j'étais débutant :

    Tu ne codes pas pour toi, tu codes pour l'utilisateur final !

    En codant de cette manière, on se rend compte qu'on atteint très vite 2 objectifs :

    - Répondre au mieux aux besoins des utilisateurs (on répond mieux à un problème si on en comprend vraiment les enjeux ), ce qui signifie moins d'anomalies fonctionnelles de leur point de vue.

    - Produire le code le plus "intelligent" possible : en comprenant le contexte du projet, on peut mieux cerner le problème et y répondre plus efficacement, notamment en termes de performances attendues, de quantité de code nécessaire et de maintenabilité de l'application.

    Pour moi, c'est ça qui fait qu'un client retient votre logiciel, pas la qualité de son code ni l'optimisation au petits oignons de chacune de ses fonctions (attention, je ne dis pas que ça ne compte pas, ces 2 points sont ceux qui font que le client garde votre programme et pas celui d'un autre).

  9. #29
    Membre expérimenté
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2010
    Messages
    254
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2010
    Messages : 254
    Points : 520
    Points
    520

    Par défaut

    Mon prof de C++ : un bon développeur est un développeur feignant.

    En gros son conseil portait sur le fait de rendre son code le plus générique possible pour éventuellement pouvoir le réutiliser plus tard dans d'autre projets.
    "L'insanité consiste à répéter la même action dans l'espoir d'aboutir à un résultat différent" Albert Einstein
    ----------------------
    T.O.A.O 6-MarViN

  10. #30
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par tomlev Voir le message
    C'est plutôt le meilleur moyen de faire un code imbitable... Commence par faire un code qui marche, élimine les bugs, et seulement à ce moment là tu pourras te préoccuper de l'optimiser.

    Premature optimization is the root of all evil
    -- D. Knuth
    Un code performant, ce n'est pas un code optimisé. A mon avis, il faut produire du premier coup un code raisonnablement efficace, parce que dans la vraie vie, on n'a jamais le temps de faire les optimisations... Et c'est comme ça qu'on se retrouve avec des programmes qui mobilisent des ressources obscenes, et qu'on n'ose plus faire évoluer de peur de mettre la machine à genoux, parce que le premier developpeur n'a pas voulu trier, faire des recherches dichotomiques, écrire ses boucles dans le bon ordre, ou se poser la question de la volumétrie... toutes choses qui ne relèvent pas de l'optimisation mais du métier de base (et qui sont disponibles dans toutes les librairies).

    Les algorithmes de Knuth sont d'ailleurs typiques de cette approche. Ils ne sont jamais optimisés, mais toujours efficaces.



    Le meilleur conseil qu'on m'ait donné, c'était "ne jamais hésiter à refaire".

    Francois

  11. #31
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2010
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Communication - Médias

    Informations forums :
    Inscription : novembre 2010
    Messages : 50
    Points : 73
    Points
    73

    Par défaut

    Ne devient pas esclave de ton code.

  12. #32
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2008
    Messages
    207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2008
    Messages : 207
    Points : 1 124
    Points
    1 124

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    ==>sur l'objectif réel du code : être beau, ou marcher?
    Je n'aime pas beaucoup ce genre de question. Déjà parce "beau" a une connotation superficielle, et qu'il est mis en comparaison avec "marcher", comme un pragmatisme superficiel évident justifiant de faire n'importe quoi.

    A mon humble avis, dans la majorité des cas, un code brouillon, pas réfléchi, mal pensé, fait perdre du temps et de l'argent à tout le monde (et n'est donc pas "fonctionnel". Et se cacher derrière l'argument de "ça marche", ça revient à, pour moi, entuber tout le monde).

    (et je ne parle pas donc pas de passer son temps sur de l'esthétique, bien au contraire, et j'insiste. Je dis juste qu'un code "fonctionnel" est d'abord un code bien pensé. C'est pas toujours évident, mais c'est ça notre boulot...)

  13. #33
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2008
    Messages
    207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2008
    Messages : 207
    Points : 1 124
    Points
    1 124

    Par défaut

    Citation Envoyé par monsieurben Voir le message
    Le conseil qui m'a le plus marqué quand j'étais débutant :

    Tu ne codes pas pour toi, tu codes pour l'utilisateur final !
    Entièrement d'accord. Et je rajouterais même "pour l'utilisateur final, et pour le gars qui va reprendre ton code". C'est un point distinct, mais tout aussi important à mes yeux.

    Parce que :
    - un code non maintenable est un code mort.
    - En plus, penser à comment le prochain dev comprendra ton code, ça te fera faire un code mieux pensé, même pour toi-même.
    - Et même si certains disent que c'est inutile car le client ne paiera pas plus à la livraison du code... Pour moi, premièrement c'est un argument ultra-bidon pour faire de la merde, et deuxièmement, dans tous les autres cas (boite d'édition, ou pour un client qui maintiendra ton code et qui ne te fera plus confiance plus tard s'il voit que tu leur a fait perdre du temps), cet argument ne s'applique plus.

    (Donc au final, ça donnerait "ne codes pas pour toi, mais pour les autres" et je crois bien que c'est l'adage que l'on retrouve souvent partout, je pense)

  14. #34
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 214
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 214
    Points : 10 750
    Points
    10 750

    Par défaut

    Citation Envoyé par Guilp Voir le message
    (.../...)(Donc au final, ça donnerait "ne codes pas pour toi, mais pour les autres" et je crois bien que c'est l'adage que l'on retrouve souvent partout, je pense)
    Y compris quand "les autres", c'est "soi-même". Revenir sur un vieux code à soi-même est une expérience qui rend humble - tant qu'on est honnête avec soi-même.

    Sinon, quand je parlais de code "beau", je faisais plus référence aux architectes astronautiques(et contrairement à l'auteur de ce texte, je ne crois pas que ça se limite au monde java). une architecture objet poussée, avec des héritages magnifiques, un graphe formidable, tout ça pour faire 3 additions, c'est beau, mais ça n'aide pas à résoudre le problème. Effectivement, un code "lisible" et "bien conçu", voire "bien dimensionné", c'est important aussi(mais par souci de concision, j'ai pu laisser entendre que j'avais un avis différent, désolé).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  15. #35
    Membre Expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2008
    Messages
    207
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2008
    Messages : 207
    Points : 1 124
    Points
    1 124

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Sinon, quand je parlais de code "beau", je faisais plus référence aux architectes astronautiques(et contrairement à l'auteur de ce texte, je ne crois pas que ça se limite au monde java). une architecture objet poussée, avec des héritages magnifiques, un graphe formidable, tout ça pour faire 3 additions, c'est beau, mais ça n'aide pas à résoudre le problème. Effectivement, un code "lisible" et "bien conçu", voire "bien dimensionné", c'est important aussi(mais par souci de concision, j'ai pu laisser entendre que j'avais un avis différent, désolé).
    (Juste pour préciser que je suis entièrement d'accord . Je faisais plus un commentaire général en réagissant sur la tournure de phrase qui me titillait les yeux. J'hésitais à préciser, par précaution, que me doutait bien que dans le fond, ça n'est pas ce que tu voulais dire, mais je ne l'ai pas fait...)

    EDIT:

    Et en fait, quand j'y repense, les architectures "astronomiques" (donc exagérées, pas adaptées au besoins), ça rentre pour moi dans plus dans un concept de "moche" plutôt que "beau" (pour rester dans le subjectif). Pour moi, un code bien pensé est en fait un code simple. (qui fait le plus simplement possible ce qu'il est sensé faire). Ce qui ne veut pas dire qu'un code simple est facile à faire, bien au contraire...

    Simple is beautifull. Ca aussi c'est une phrase que mon prof m'enseignait en dernière année de fac et qui m'a marquée.

  16. #36
    Expert Confirmé Avatar de ManusDei
    Homme Profil pro
    esclave du Grand Capital
    Inscrit en
    février 2010
    Messages
    1 280
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : esclave du Grand Capital

    Informations forums :
    Inscription : février 2010
    Messages : 1 280
    Points : 2 923
    Points
    2 923

    Par défaut

    Citation Envoyé par VivienD Voir le message
    Euh... sinon... ça veut dire quoi «factoriser un code» ?
    Au lieu de faire une fonction qui ajoute X à tous les élements d'une liste (renvoyant X'), une fonction qui va appliquer une fonction Y à chaque élement d'une liste (renvoyant Y'), une fonction qui va récupérer l'information Z de chaque élément d'une liste (renvoyant Z', liste des informations), tu fais une fonction qui prend en paramètre une liste L et une fonction F, et qui applique F à chaque élement de L, renvoyant L'.

    Bref tu factorises 3 fonctions (à but unique) en une seule (qui a plusieurs utilisations possibles).

    C'est parfois un poil plus compliqué à relire, mais si il y a un bug dans ta gestion des listes, tu n'auras pas à traquer chacune des fonctions appliquées à X Y et Z pour corriger un bug.

    Ca c'est un exemple simple, souvent déjà prévu dans la bibliothèque de base du langage, mais c'est pour expliquer le principe.
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  17. #37
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 882
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 882
    Points : 6 881
    Points
    6 881

    Par défaut

    Comprends ce que tu fais

    Ça peut paraitre simple, mais ça ne l'est pas. Parce qu'on peut aller très loin dans la compréhension : Ok, tu fais du Java. Mais est-ce que tu sais comment fonctionne la JVM ? Le garbage collector ? Est-ce que tu connais le bytecode ?

    Bien connaitre les fondements des outils, des principes, des langages, des méthodes qu'on utilise, c'est toujours payant, à la fin.

    Aborde chaque problème avec naïveté

    C'est en supposant plein de choses qu'on obtient un truc pas terrible à la fin.

    N'ai pas peur de casser ce que tu as fait

    Tout le monde écrit du code qui finit à la poubelle avant d'avoir jamais été utilisé. C'est normal, et même très bien. Si tu trouve une meilleure solution que ce que tu as déjà fait, n'hésite pas à refaire. sur le long terme, tu seras gagnant.
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  18. #38
    Membre du Club Avatar de betadev
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2008
    Messages
    92
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2008
    Messages : 92
    Points : 58
    Points
    58

    Par défaut

    Pour moi , le plus important c'est de réfléchir au étapes à franchir lorsqu'on développe , étape par étape , de ce qui est général à ce qui est très spécifique
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    La programmation ce n'est pas de la magie , c'est simplement de la logique

  19. #39
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 190
    Points : 4 893
    Points
    4 893

    Par défaut

    Comme beaucoup, pas un mais plusieurs conseils en tout cas c'est ceux que je suis tous les jours. Ils recoupent ceux déjà cités par les gourous, membres de DVP, et ils recoupent également entre eux mais chacun avec sa petite spécificité :
    • DRY
    • KISS
    • Réduire le problème à sa plus simple expression
    • Mieux vaut un qui sait que dix qui cherchent
    • Toujours exprimer ses idées par des phrases


    Je détaille le dernier tant ca me sert dans mes heures les plus sombres. Si je cherche une solution à un problème, le fait d'exprimer mon problème avec des phrases permet dans 80% des cas de résoudre le problème. Je remercie d'ailleurs tous mes différents voisins pour avoir supporté que je commence une question et de les remercier avant d'avoir fini de la poser ^^
    Idem quand je suis un peu perdu dans une réflexion ou que je pars un peu dans tous les sens, ca me permet de remettre les choses à plat.

    Pour info :
    Citation Envoyé par Willy_XIII Voir le message
    camelCase vs under_score
    snake_case
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  20. #40
    Expert Confirmé
    Avatar de Golgotha
    Homme Profil pro
    Full-stack Web Developer
    Inscrit en
    août 2007
    Messages
    1 213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Full-stack Web Developer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2007
    Messages : 1 213
    Points : 2 737
    Points
    2 737

    Par défaut

    Beaucoup de bon conseil

    Je rajouterais pour ma part, de toujours travailler avec des briques "simples". Ne faites jamais des fonctions de plus de 20 lignes par exemple. Cela permet de toujours décomposer le problème, d'y voir plus claire.

    Quand mon code deviens complexe, je me dis que je vais dans la mauvaise direction.
    modérateur webmasters - développements web & php
    faq jQuery - règles du forum - faqs web

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •