IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Quelles règles les programmeurs débutants devraient-ils toujours respecter ?

  1. #61
    Futur Membre du Club
    Inscrit en
    Mai 2011
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Mai 2011
    Messages : 2
    Points : 5
    Points
    5
    Par défaut
    Salut,

    Pour ce qui est de "commenter le plus possible" (et il y a même eu la suggestion de poser un algorithme en commentaire avant de l'implémenter) je ne suis pas du tout d'accord.

    Pour moi, un commentaire, c'est tout d'abord un échec. C'est ne pas avoir été capable de produire du code de qualité, logique et autodocumenté.
    Alors effectivement il y a des commentaires utiles et nécessaires, mais chez les débutants à l'université chez nous (Berlin) je vois surtout des commentaires du type

    // addition des deux masses pour avoir la masse totale
    int j = i + k;

    alors que
    int masseTotale = masse1 + masse2;
    ferait très bien l'affaire.

    98% des commentaires que je vois sont redondants, superflus, ne collent pas avec le code (là c'est le worst case, un commentaire pas mis à jour alors que le code a été patché, on ne sait plus que croire), n'apportent rien, indiquent la structure low level du code alors que le commentaire est sur une fonction abstraite, bref, avec du bon code le commentaire serait complètement inutile (et le débutant qui code avec des noms de variables à la n, m, i, j, k juste pour expliquer en commentaire ce que ca veut dire c'est vraiment l'un des pires crimes à commettre).

    Edit : Sans vouloir faire de la pub, il y a un bouquin absolument ENORME (génial) sur le sujet (en anglais) qui s'appelle "Clean Code" de Robert C. Martin.
    Si j'avais le choix, j'obligerais tout débutant à le lire et à l'assimiler en entier avant d'écrire ne serait-ce qu'un hello world.

  2. #62
    Membre averti
    Profil pro
    Inscrit en
    Juillet 2009
    Messages
    162
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2009
    Messages : 162
    Points : 301
    Points
    301
    Par défaut
    Citation Envoyé par maxinator Voir le message
    Salut,
    98% des commentaires que je vois sont redondants, superflus, ne collent pas avec le code (là c'est le worst case, un commentaire pas mis à jour alors que le code a été patché, on ne sait plus que croire)
    La mise à jour des commentaires fait partie du boulot du développeur! Ca ne me viendrait pas à l'esprit de changer du code sans changer le commentaire qui va avec. Ca serait d'ailleurs une autre règle à apprendre au développeur débutant.

    Par ailleurs, même je suis d'accord qu'un nommage cohérent des variables et des méthodes permet d'éviter des commentaires, on n'est pas non plus dans Matrix à lire du byte code à l'oeil nu! Quelques commentaires bien placés permettent de donner la direction générale de l'algo sans avoir à comprendre chaque ligne de code. En plus (mais ça c'est subjectif) je trouve que ça aère le code.
    Maintenant, un bon commentaire décrit le pourquoi pas le quoi.

  3. #63
    Futur Membre du Club
    Inscrit en
    Mai 2011
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Mai 2011
    Messages : 2
    Points : 5
    Points
    5
    Par défaut
    Citation Envoyé par benzoben Voir le message
    Par ailleurs, même je suis d'accord qu'un nommage cohérent des variables et des méthodes permet d'éviter des commentaires, on n'est pas non plus dans Matrix à lire du byte code à l'oeil nu! Quelques commentaires bien placés permettent de donner la direction générale de l'algo sans avoir à comprendre chaque ligne de code. En plus (mais ça c'est subjectif) je trouve que ça aère le code.
    Maintenant, un bon commentaire décrit le pourquoi pas le quoi.
    Dans la plupart des projets que j'ai suivis presque tous les commentaires sont à supprimer.
    Dans le projet tomcat par exemple, il y a plein de sources avec des commentaires plus longs que les fonctions qu'ils commentent.
    Il y a aussi plein de commentaires sur des noms de variables, alors que le nom de la variable est souvent plus clair que le commentaire.

    Si ca aère le code, pourquoi pas!
    J'ai un binôme qui commente beaucoup et c'est très agréable à lire et à comprendre chez lui. J'ai un autre binôme qui me pond des noms de variables à la "int csharpsucksiknowwhatimdoing = 42;" ....

    Mais pour un vrai débutant je pense que c'est plus facile de ne pas commenter que de bien commenter. J'ai pas encore vu de débutants implémenter du Rayes Rendering

    Citation Envoyé par benzoben Voir le message
    La mise à jour des commentaires fait partie du boulot du développeur!
    Si tu fais un tour sur quelques projets open source, tu trouves même pire : des noms de variables en hungarian notation (le type en préfixe au nom, comme "listUser" pour une liste de users). Après un patch le type change (un array au lieu d'une liste par exemple) mais le développeur "oublie" d'actualiser le nom et l'on se retrouve devant un array qui s'appelle listUsers

  4. #64
    Membre éprouvé Avatar de cs_ntd
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2006
    Messages
    598
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

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

    Informations forums :
    Inscription : Décembre 2006
    Messages : 598
    Points : 1 214
    Points
    1 214
    Par défaut
    Citation Envoyé par Reward Voir le message
    Pas d'accord avec ça. N'as-tu jamais vu de contrat en alternance dans ton entreprise, des apprentis ? Ils sont étudiants et ont leur place en entreprise, puis il faut bien commencer un jour.

    Tu as donc commencé ton travail dans le développement en étant directement expérimenté, sans passer par la case débutant ? Intéressant !
    Citation Envoyé par gwinyam Voir le message
    Bravo l'ouverture d'esprit professionnelle. Tout comme le suggère Reward, les contrats d'apprentissage, les stages, ça sert à quoi? Justement à ça, à apprendre.
    N'importe quoi, tous les deux, il faut réfléchir un peu avant de critiquer...

    Prenons les satges par exemple : alors certe, le stagiaire est souvent un étudiant oui (ou est-ce que j'ai dit qu'ils ne pouvaient pas travailler en entreprise ?), mais ce n'est certainement pas un débutant en informatique.
    C'est peut etre un débutant en tant que salarié, qui découvre le monde de l'entreprise, et la facon de travailler dans un entreprise. Mais ce n'est pas un débutant en informatique.

    Dans un DUT, le stage ce fait après 2 ans d'étude, alors certe, ca ne garantit pas que l'étudiant soit bon, mais on peut difficilement dire qu'il est débutant !
    Et meme pour certains BTS ou c'est que après 1 ans, meme si il y a de forte chance qu'il manque d'experience, le stagiaire est quand meme supposé avoir des connaissances en informatique.

    Et quand aux formations par alternance, je n'en connait aucune qui prenne directement après le bac en informatique, et qui peut donc prendre potentiellement des gens qui n'ont pas la moindre connaissance.
    Mais admettons que ca existe. Donc vous avez dans votre entreprise un nouveau venu (qui ne sais meme pas ce que c'est qu'un IF), et vous allez le mettre sur un de vos projets clé pour developper, vraiement ?


    Enfin bon, un débutant, c'est quelqu'un qui ne connait rien a l'informatique. Ce n'est pas quelqu'un qui a fait 2 années d'études dans le domaine (l'article suggère visiblement qu'on est débutant pendant les 6 premieres mois...)


    Et pour finir :
    Citation Envoyé par gwinyam Voir le message
    Faut arrêter l'idée de l'informaticien auto-didacte qui apprend dans sa piaule comme un gros galérien et qui est apte à aller en entreprise ensuite. C'est pas professionnalisant comme comportement.
    Mais de quoi tu parles ? Moi je parlais de personnes dont l'informatique n'est pas leur métier, mais que ca interesse, qui ont acheté un bouquin sur le sujet, et qui apprenne tranquillement chez eux le soir, en rentrant de leur boulot. Juste pour le plaisir.

    The magic of Opera, La magie de l'Opera
    The mysteries of Space Opera, Les mystères de l'Opera Spatial
    Mr. Know-it-all, M. Je-Sais-Tout
    Prelude in C sharp minor, the most beautiful piano song and the best C sharp prelude ever, Prélude en do dièse mineur, le plus beau morceau de piano et le meilleur prélude au C#
    The Mesmerizing Saphir Division for Nerds, L'Hypnotisante Division Saphire pour les Nerds (HDSN)

  5. #65
    Membre chevronné
    Avatar de gwinyam
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mai 2006
    Messages
    1 162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2006
    Messages : 1 162
    Points : 2 015
    Points
    2 015
    Par défaut
    Citation Envoyé par cs_ntd Voir le message
    Et quand aux formations par alternance, je n'en connait aucune qui prenne directement après le bac en informatique, et qui peut donc prendre potentiellement des gens qui n'ont pas la moindre connaissance.
    BTS Informatique de Gestion, par alternance. J'en connais suffisamment qu'ils l'ont fait pour savoir que ça existe.

    Et de mon point de vue, t'auras beau avoir fait des études en informatique, ok tu auras un minimum correct de notions, mais les vraies connaissances, c'est sur le terrain. Je me suis coltiné 6 ans d'études, j'ai fait 2 écoles d'ingé, j'ai les diplômes qui vont avec, j'étais pas le plus mauvais de mes promos, et de loin, et je prends quand même des claques tous les jours au boulot parce que j'ai pas encore assez de terrain dans les jambes.

    Les débutants ont leur place en entreprise. ça fait 3 ans que je bosse, et pour autant, je suis toujours un débutant face à mes collègues. Et je l'assume sans complexe. Pourtant j'ai mérité et mérite toujours ma place.
    Comparez la qualité et le prix du matériel de bricolage ou de maison avant d'acheter : MatosMaison
    Le bouton ne masse pas les pieds, mais ça aide la communauté.

  6. #66
    Membre éprouvé Avatar de cs_ntd
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2006
    Messages
    598
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

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

    Informations forums :
    Inscription : Décembre 2006
    Messages : 598
    Points : 1 214
    Points
    1 214
    Par défaut
    Alors on est apparement pas d'accord sur la définition d'un débutant en informatique. Moi un débutant, c'est un personne qui ne sais meme pas ce que c'est que de la programmation (et qui va apprendre ca a l'école). Et qui, si il fait des études, va rester débutant pendant 5/7 mois.

    Alors, c'est sur que si pour toi, quelqu'un qui a fait "6 ans d'études", "2 écoles d'ingé" et qui a "les diplômes qui vont avec", et sans etre "le plus mauvais de [ses] promos, et de loin", et qui bosse désormais depuis 3 ans, si tu penses que cette personne peut etre considérée comme un débutant, forcément, les entreprises sont peuplées de débutant, et meme de sous-débutant alors .......


    Quand tu dit :
    je suis toujours un débutant face à mes collègues
    je ne suis pas d'accord avec ta formulation. Si c'était mon cas, j'aurais dit,
    Je suis toujours moins expérimenté que mes collègues
    Et comme personne n'a la science infuse, on trouvera toujours quelqu'un de meilleur que soit...

    Mais tu changerais d'entreprise, dans une startup toute nouvelle, ou tu serais le leader, tu ne serais plus considéré comme un "débutant". Donc il y a un problème avec cette définition du débutant, puisqu'elle dépends du contexte...

    The magic of Opera, La magie de l'Opera
    The mysteries of Space Opera, Les mystères de l'Opera Spatial
    Mr. Know-it-all, M. Je-Sais-Tout
    Prelude in C sharp minor, the most beautiful piano song and the best C sharp prelude ever, Prélude en do dièse mineur, le plus beau morceau de piano et le meilleur prélude au C#
    The Mesmerizing Saphir Division for Nerds, L'Hypnotisante Division Saphire pour les Nerds (HDSN)

  7. #67
    Membre chevronné
    Avatar de gwinyam
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mai 2006
    Messages
    1 162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2006
    Messages : 1 162
    Points : 2 015
    Points
    2 015
    Par défaut
    Là on est d'accord, un débutant pur et dur n'a rien à faire en entreprise si il n'a même jamais touché une souris.
    Ceci dit, se lancer dans l'informatique comme profession sans y avoir jamais touché, c'est un peu du suicide professionnel quoi.
    Comparez la qualité et le prix du matériel de bricolage ou de maison avant d'acheter : MatosMaison
    Le bouton ne masse pas les pieds, mais ça aide la communauté.

  8. #68
    Membre régulier Avatar de Djromé
    Profil pro
    Inscrit en
    Juillet 2009
    Messages
    172
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2009
    Messages : 172
    Points : 93
    Points
    93
    Par défaut
    Salut les Kracks,

    Sans être programmateur, j'ai appris le VBA en utilisant le pas-à-pas et en copiant-collant des bouts de code piqués ou gracieusement donnés par la plupart d'entre vous (en vous remerciant). Il est vrai que l'important est de bien comprendre ce que l'on fait (lire les codes VBA n'est pas bien compliqué quand ils sont bien fait) mais les problèmes arrivent dans le complexe voir même dans le très simple, pour vous. Je m'explique, rien que de bien comprendre comment utiliser les différentes fenêtres et outils proposés peut être rébarbatif si personne ne vous l'a expliqué auparavant. Il y a des sites bien fait, dont celui-ci, mais pour moi les commentaires des actions du programme devraient être expliquer chaque fois (on a beau répéter plusieurs fois aux enfants de ne pas traverser la route, ça rentrera quand même en insistant), surtout pour les programmeurs occasionnels (ne me grondé pas, je souhaiterai juste m'attabler avec vous ;-). Le copier-coller des codes dépanne, mais ne soigne pas!
    Merci les kracks,

    Apprendre à un imbécile, c'est comme soigner un mort
    "alors avec moi, bon courage!"
    (дурака учить, что мертвого лечить, c'est plus beau en Russe!)

  9. #69
    Futur Membre du Club
    Profil pro
    Inscrit en
    Septembre 2008
    Messages
    5
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2008
    Messages : 5
    Points : 5
    Points
    5
    Par défaut Longueur d'une méthode
    Je ne suis absolument pas d'accord avec le premier point. Scinder son code en X méthodes simplement pour limiter le nombre de lignes nuit gravement à la lisibilité du code. Pour lire et comprendre ce dernier, il faut alors sauter d'une méthode à l'autre, et on perd le contexte à chaque fois. Il vaut mieux utiliser des régions quand le langage supporte cette fonctionnalité ou les blocs repliables au niveau de l'IDE. Le code ne doit être déporté dans une méthode ou une fonction que si il est utilisé à plusieurs endroits.

    Evidemment en VB.NET, comme on ne peut pas utiliser les régions dans le corps d'une méthode, on est obligé de scinder le code autrement. C'est une des raisons qui font que je n'apprécie pas trop ce langage.

  10. #70
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Points : 5 724
    Points
    5 724
    Par défaut
    Citation Envoyé par mdelanno Voir le message
    Je ne suis absolument pas d'accord avec le premier point. Scinder son code en X méthodes simplement pour limiter le nombre de lignes nuit gravement à la lisibilité du code.
    Découper ses méthodes en méthodes plus petites (et donc limiter le nombre de lignes de code par méthode) n'a rien à voir avec la lisibilité du code, c'est une réponse de conception qui ne se limite pas simplement à limiter le nombre de ligne pour limiter le nombre de ligne de code.

    En effet, plus c'est gros plus c'est fatalement plus compliqué et la réponse à un problème complexe et gros c'est son découpage en unité plus petite et donc plus simple.

    Bien ordonner ses méthodes (l'ordre d'apparition dans la classe) cela augmente la lisibilité du code puisqu'un fichier source, à l'instar d'un journal pour reprendre les termes du livre Code Propre, on va le lire de haut en bas.
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  11. #71
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Vous me faites marrer avec votre "un débutant n'a rien à faire en entreprise".

    Un certain nombre de développeurs de 40 ans et plus dont certains peuvent passer pour des experts ont appris à programmer sur le tas, en entreprise. Ils ne sont pas passer par l'école pour apprendre à programmer.

    Et quand on voit certains stagiaires et débutants arrivés, pourtant sortant d'école d'ingé, etc... avec toutes leurs théories, préjugés et leur suffisance (moi je suis ingénieur, même s'y j'y connais rien), on se dit parfois, qu'ils auraient mieux fait de ne pas passer par la case école et d'apprendre directement en entreprise. Surtout quand il faut passer 6 mois à leur faire oublier ce qu'ils ont vu en école, et leur réapprendre tout.

    Mais cela est de moins en moins possible, surtout quand les entreprises (SSII en particulier) recherche des jeunes de moins de 6 mois d'expérience (ça coute moins cher à payer) mais avec un bagage et des connaissances dignes d'un senior de plus 15 d'expérience.
    --- Sevyc64 ---

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

  12. #72
    Membre averti
    Inscrit en
    Décembre 2007
    Messages
    222
    Détails du profil
    Informations forums :
    Inscription : Décembre 2007
    Messages : 222
    Points : 434
    Points
    434
    Par défaut
    Citation Envoyé par Hinault Romaric Voir le message
    Six, le débutant doit éviter l'abstrait, et toujours opter pour le concret.

    Et vous ?

    Quelles sont vos « 7 Règles d'Or » de la programmation ?

    Et que pensez-vous de ces règles de Paul Vick?

    Source : Blog Paul Vick
    J'aimerai beaucoup savoir comment différencier abstrait et concret en programmation...

    Sinon, ma règle N°1 : ne jamais écouter les vieux barbons qui croient tout savoir et ont peur pour leur poste à cause de leurs connaissances obsolètes cristallisées en dogmes.
    La sécurité de l'emploi
    "Ce n’est pas une pratique médicale sensée que de risquer sa vie en se soumettant à une intervention probablement inefficace afin d’éviter une maladie qui ne surviendra vraisemblablement jamais."
    Docteur Kris Gaublomme, médecin belge ("Vaccins et maladies auto-immunes")

  13. #73
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Janvier 2007
    Messages : 185
    Points : 469
    Points
    469
    Par défaut
    Je suis d'accord avec tous le monde, la règle numéro 1 est commenter son code et cette règle est pour moi indétrônable. Un corollaire à cette règle serai de nommer le nom de ses variables et ses procédures le plus explicitement possible quitte à produire des noms à rallonge (tout en respectant les règles de nommage des langage utilisés). Réveillez vous les écrans limités à 80 colonnes ça n'existe plus ! Je vois trop souvent des lignes de code automatiquement coupées à 80 colonnes, je trouve ça complètement ridicule avec les résolutions incroyables des LCD actuels. Donc nourrissez vos lignes de code avec du commentaire, je préconise au minimum 50% de commentaires dans un fichier source, du plus basique car ce qui est basique pour vous ne l'est pas pour d'autre et inversement, et ce jusqu'au plus éloquent pour résumer un point fonctionnel en en-tête d'une procédure par exemple. Nommer correctement vos variables (et membres de classe) participe à la compréhension du code, les noms raccourcis n'ont de signification que pour vous et puis écrire du code ce n'est pas comme rédiger une petite annonce dans un journal ! Et ceux qui prétendent que cela nuit à la lisibilité du code doivent certainement utiliser de très vieux éditeurs (non pas de nom svp) qui ne connaissent pas la colorisation syntaxique ou d'autres facilités offertes par les éditeurs modernes (commentaires cachés par ex). C'est vrai qu'à une époque on pouvait s'affranchir de tous ces principes car en général un seul développeur écrivait et maintenait son propre code. Maintenant les équipes changent rapidement, la maintenance est en général un autre secteur de l'entreprise prise en charge par d'autres équipes voir d'autres sociétés spécialisées. Donc ne travaillez plus comme si vous étiez seul au monde, certain me dirons oui mais le développeur est par définition autiste, certe mais son travail ne pourra être valorisé que si il suit des principes et cela ne demande véritablement pas beaucoup d'effort. Je laisse le soin aux autres d'énumérer les autres règles (tests unitaires, découpage du code, multilevel logging, maitrise du langage etc ...).

    PS: merci à maxinator pour la référence "Clean code"

  14. #74
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Citation Envoyé par Jitou Voir le message
    Donc nourrissez vos lignes de code avec du commentaire, je préconise au minimum 50% de commentaires dans un fichier source,
    50% soit 1 ligne de commentaire pour un ligne de code, c'est trop.

    La règle communément admise c'est de 6 à 10% soit en gros une ligne de commentaire pour 10 à 15 lignes de code.
    Ou, pour ce qui préfèreront, de 1 à 3 lignes de commentaire en début de chaque procédure et fonction.

    Et c'est largement suffisant, car avec un code correctement découpé et agencé, des nom de variables et méthodes judicieusement choisis et suffisamment explicites, la plupart des commentaires sont superflus
    --- Sevyc64 ---

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

  15. #75
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Janvier 2007
    Messages : 185
    Points : 469
    Points
    469
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    50% soit 1 ligne de commentaire pour un ligne de code, c'est trop
    Oui j'ai peut être eu la main lourde mais je ne pensais pas non plus alterner nécessairement 1 ligne de code avec 1 ligne de commentaire ! Par contre des commentaires en début de méthode c'est insuffisant il faut commenter là où c'est nécessaire il faut penser le commentaire comme une aide contextuelle que l'on peut escamoter où afficher à loisir. Il ne faut pas incriminer les débutants au contraire car ce sont les plus aptes à adopter de nouvelles méthodes de travail pour peux qu'on les coach un peu. Par contre j'ai déjà vu des développeurs senior géniaux mis au placard simplement parce qu’ils étaient incapables de produire du code maintenable, une véritable perte sèche pour l'entreprise qui se trouve alors dans l'impossibilité de valoriser leur travail.

  16. #76
    Membre chevronné
    Avatar de gwinyam
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mai 2006
    Messages
    1 162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2006
    Messages : 1 162
    Points : 2 015
    Points
    2 015
    Par défaut
    Citation Envoyé par OWickerman Voir le message
    J'aimerai beaucoup savoir comment différencier abstrait et concret en programmation...
    Soit tu fais le truc terre à terre et tu doublonnes du code, soit tu abstrais au maximum, ce qui te permet de ne pas doubler le code mais devient plus difficile pour quelqu'un qui démarre sur les notions de base. Typiquement, il est plus facile pour un débutant de comprendre l'encapsulation puis l'héritage plutôt que l'encapsulation et l'héritage en même temps.
    Comparez la qualité et le prix du matériel de bricolage ou de maison avant d'acheter : MatosMaison
    Le bouton ne masse pas les pieds, mais ça aide la communauté.

  17. #77
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Citation Envoyé par gwinyam Voir le message
    Soit tu fais le truc terre à terre et tu doublonnes du code, soit tu abstrais au maximum, ce qui te permet de ne pas doubler le code mais devient plus difficile pour quelqu'un qui démarre sur les notions de base. Typiquement, il est plus facile pour un débutant de comprendre l'encapsulation puis l'héritage plutôt que l'encapsulation et l'héritage en même temps.
    Question de mesure, la seule chose qui compte à mon sens dans un code, c'est qu'il réponde au besoin et soit facile à maintenir. Je suis toujours partant de dire qu'il faut considérer la séparation des couches (le fameux 3 tiers), le concept "dry" et autres pratiques architecturales comme étant des façons **générales** de penser du code, mais en aucun cas comme des règles gravées sur pierre.

    Quant aux design patterns, polymorphisme et l'orienté objet en général, ce sont juste des outils pour parvenir à son but. Les best practices ont beau dire et répéter qu'un pull-up est nécessaire chaque fois que 2 classes partagent ne serait-ce qu'une propriété get/set en commun, il existe des cas où une application trop stricte de cette "vérité universelle" peut vous donner des hiérarchies complètement folles, inutilement complexes et qui réduisent beaucoup votre marge de manoeuvre en cas de modification.
    La même chose existe pour la plupart des DP, se forcer à les utiliser peut avoir des conséquences catastrophiques et aboutir à l'introduction de complexités supplémentaires.

    La sur-abstraction et l'over-engineering sont pour moi parmi les plus grands ennemis du programmeur, débutant ou pas. Et ces deux pièges techniques sont exacerbés par l'omniprésence de frameworks pleins de "voodoo magic" qui vous laissent penser que vous pouvez vous déresponsabiliser de votre système de persistence et autres.

    Je pense qu'il faut prendre ce recul par rapport à tous les bons conseils théoriques et best practices qu'on se plaît à nous rabâcher. Celui qui se retrouve devant son projet avec des délais à tenir et des impératifs de qualité, c'est vous, c'est pas Paul Vike, Martin Fowler, ou Dieu sait quel donneur de leçon dont vous avez cru bon de respecter les principes à la lettre.

  18. #78
    Membre éclairé Avatar de tigunn
    Homme Profil pro
    Développeur de bug
    Inscrit en
    Janvier 2003
    Messages
    608
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de bug

    Informations forums :
    Inscription : Janvier 2003
    Messages : 608
    Points : 658
    Points
    658
    Par défaut
    A l'image des Robots d'Asimov, je vais ajouter une règle, la règle qui prévaut toutes les autres: "Ne te précipite pas, réfléchis, analyse bien; puis, ensuite, code"!!!!!
    parce qu'il n'y a rien de pire qu'une méthode mal conçu, à part une classe inutile.
    Le monde se divise en deux: ceux qui utilisent le tag et les autres.

  19. #79
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    Quelles sont vos « 7 Règles d'Or » de la programmation ?
    Je n'en ai qu'une, érigée en précepte fondamental, voir en dogme philosophique :

    "Commence par demander à ceux qui savent"




    (Toute publicité pour le forum DVP ne serait pas forcément fortuite )
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  20. #80
    Expert confirmé
    Avatar de RomainVALERI
    Homme Profil pro
    POOête
    Inscrit en
    Avril 2008
    Messages
    2 652
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : POOête

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 652
    Points : 4 164
    Points
    4 164
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    "Commence par demander à ceux qui savent"
    Bien que je sois d'accord sur le principe, il est rarement facile de déterminer qui sait puisque précisément, on ne sait pas.

    Mais effectivement, c'est à la fois très précieux et assez souvent marrant d'échanger des connaissances ici, ne nous en privons pas

    ...pour les linguistes et les curieux >>> générateur de phrases aléatoires

    __________________

Discussions similaires

  1. Les développeurs Linux devraient-ils s’intéresser à Mono ?
    Par Olivier Famien dans le forum Actualités
    Réponses: 36
    Dernier message: 06/07/2015, 08h53
  2. Pourquoi les programmeurs systèmes sont-ils trop attachés au C ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 81
    Dernier message: 18/05/2015, 10h55
  3. Quelles pratiques les développeurs devraient-ils éviter ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 53
    Dernier message: 18/03/2015, 19h18
  4. Les jeunes diplômés devraient-ils travailler "pour du beurre" ?
    Par Katleen Erna dans le forum Actualités
    Réponses: 180
    Dernier message: 17/03/2011, 18h35
  5. Réponses: 0
    Dernier message: 30/06/2009, 12h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo