Que doit savoir chaque programmeur?


245

Quels que soient le (s) langage (s) de programmation ou le (s) système (s) d'exploitation utilisé (s) ou l'environnement pour lequel ils développent, que doit savoir tout programmeur?

Quelques antécédents:

Je suis intéressé à devenir le meilleur programmeur que je peux. Dans le cadre de ce processus, j'essaie de comprendre ce que je ne sais pas et cela me serait très utile si je le faisais. Bien qu'il existe de nombreuses listes autour de "tout ce que tout développeur [langage de programmation] doit savoir", je n'ai encore rien trouvé de similaire qui ne se limite pas à un langage spécifique.

Je m'attends également à ce que cette information présente un intérêt et profite aux autres.

Réponses:


636

Comment avaler sa fierté et admettre ses erreurs sans les prendre personnellement.


60
C’est quelque chose que tout être humain devrait faire quel que soit son emploi (sexe, religion, culture, statut social, etc.), vous ne pensez pas? ;)

3
Oh oui. Mais nous, les programmeurs (du moins moi) avons tendance à être plus fiers que la plupart des autres :-)

17
J'aimerais pouvoir vous voter deux fois.

4
Je pense que c'est une chose que j'ai apprise à l'université. Au lycée, j'ai toujours été l'un des enfants les plus intelligents. Si je n'étais pas allé à l'université, j'aurais pensé que j'étais plutôt intelligent et que j'avais un grand ego. Aller à la fac et interagir avec des gens qui étaient vraiment plus compétents, m'a aidé à comprendre à quel point j'étais
idiote

4
Bien que cela soit très vrai, le problème n'est pas toujours le déni ou un grand ego, mais les conséquences potentielles d'admettre ouvertement de commettre des erreurs, du moins pas sans une sorte de légitime défense / contrôle des dégâts au préalable. Parfois, c'est une chose culturelle. :)

309

Comment penser comme un utilisateur et non comme un programmeur geek expérimenté?


2
Je trouve toujours ironique que la plupart des acteurs du secteur qui manquent semblent être l’une des compétences les plus importantes à acquérir: les compétences en communication.

Je ne pourrais pas être plus d'accord avec cela. Cela devrait être # 1.

23
Je ne suis pas d'accord C'est pour ça que vous embauchez des gens. Vous ne serez jamais capable de penser comme un utilisateur, mais vous pouvez certainement demander à des personnes de vous dire ce que les utilisateurs pensent et de donner suite à ces conseils. Il suffit de ne pas demander aux utilisateurs comment ils pensent! C'est la pire option de toutes.

1
Vous pouvez engager d'autres personnes pour le faire, mais si votre équipe de développement peut comprendre comment un utilisateur pense, alors vous aurez beaucoup moins d'arguments et d'itérations avant que les choses ne se passent bien. De plus, si un développeur peut penser comme un utilisateur, qui sait quelles nouvelles fonctionnalités il proposera

3
L'utilisateur peut très bien être un programmeur expérimenté en technologie, mais moins probablement un programmeur expérimenté en technologie qui a également implémenté le code . Si l'application a une sémantique / comportement très subtile et complexe, la personne qui a écrit le code pourrait être la seule personne qui puisse comprendre comment utiliser l'application ...
Reuben

244

Quand demander de l'aide, et quand NE PAS demander de l'aide.


2
Tellement vrai. Dernièrement, la réponse a surgi dans ma tête alors que je demandais à quelqu'un. :(
kevindaub

alors, quelle est la réponse?)

28
Demandez d'abord à votre duckie en caoutchouc. S'il ne peut pas vous aider, alors demandez à quelqu'un d'autre ...
Dean Rather

3
upvoted parce que quand j'ai commencé, je ne réalisais pas à quel point j'ennuyais les autres développeurs en leur demandant continuellement des trucs simples que je devrais comprendre moi-même jusqu'à ce que j'aie quelque chose à faire.

1
Je me pose toujours une question du type "Que dirait mon collègue si je leur posais la question". Habituellement, cela m'aide à approfondir un peu le problème avant de devoir poser la question.

184

Comment lire le code des autres


102
Addendum: Comment écrire du code que d'autres personnes peuvent lire

42
Addendum # 2: Comment lire votre propre code 6 mois plus tard

10
@Nathan Koop: Cela devrait être mieux "Comment écrire du code afin que vous puissiez le lire vous-même 6 mois plus tard".
Doc Brown

4
Quand cela fait 6 mois, c'est déjà devenu le code de quelqu'un d'autre. En ce sens que vous avez évolué depuis, que vous vous êtes amélioré et que c'est peut-être quelqu'un d'autre qui l'a écrit en premier lieu, alors traitez-le comme tel.
MPelletier le

7
Addendum # 3: Comment lire votre code 6 minutes plus tard.
mardi

152

Familiarité avec les systèmes de contrôle de version. Il n'est pas nécessaire que ce soit tout le monde, mais les concepts de base qui peuvent être appliqués à tous doivent être connus.


et que le contrôle de révision n'est pas un logiciel
jrhicks

4
J'ajouterais qu'il y a une différence assez significative entre les SCM centralisés (par exemple, subversion, CVS) et les SMC distribués (par exemple, git, mercurial, bazar) qu'il est important d'apprendre chacun d'entre eux.
Intuition le

128

Voici mes 10 bits:

  • Comment être humble. Nous sommes tous ici pour apprendre. Vous êtes peut-être plus intelligent que les autres, mais il y a beaucoup de gens plus intelligents que vous.
  • Comment étudier / consommer des informations. Je ne sais pas pour vous, mais j'étudie pour toujours! Les livres, Internet, peu importe!
  • Qu'est-ce qu'un dictionnaire et comment l'utiliser, et comment trouver rapidement des acronymes.
  • Quels sont les outils de base du métier et que font-ils (IDE, CVS et autres).
  • Connaître les terminologies communes et leur signification: modèles de conception, utilisabilité, tests (ha!), Pile, etc.
  • Avoir une compréhension de la POO.
  • Soyez «capable» dans au moins une langue, rien d’extraordinaire, il vous suffit de savoir identifier les variables et les méthodes, etc. À partir de là, vous pouvez apprendre RAPIDE.
  • Comprenez que les gens finissent par utiliser des logiciels et veulent rendre ces gens heureux.

38
Ce doit être un post octal.
Même Mien

10
En ce qui concerne la première partie ... "Ne soyez pas si humble, vous n'êtes pas si bon".
Magnus

@TheOtherScott, belle prise lol, mais je disais en fait 2 bits: D;)

3
Concernant le point 3: www.acronymfinder.com
Jasper Bekkers Le

1
@ jasper / intuited: il suffit de taper l'acronyme dans google pour afficher l'un ou l'autre ... la réponse est généralement l'un des 10 premiers résultats. plus d'informations peuvent être obtenues en cliquant!
mardi

104

C’est peut-être trop subtil, mais je pense que c’est "savoir quel problème résoudre." Beaucoup de programmeurs (et de gens normaux) font un effort énorme pour résoudre des problèmes qui ne sont tout simplement pas très importants. ou bien ils créent une solution, avec beaucoup de travail supplémentaire, ce n’est pas vraiment ce dont on a besoin.


4
D'accord, s'inquiéter des scénarios de cas d'utilisation marginaux que seul un petit nombre d'utilisateurs rencontrera à la place de fonctionnalités plus centrales est un piège bien courant! J'apprends encore celui-ci à la dure ...
Ian Robinson

Je devrais mettre un lien vers votre réponse en tant que page d'accueil de mon ancien chef d'équipe. Tu as tellement raison.

4
J'adore le fait que vous disiez "beaucoup de programmeurs (et de gens normaux)" :-)

95

Comment se détendre C'est le secret de la productivité.

Finalement, la volonté et la caféine ne suffisent pas. Cette contraction constante que nous faisons est très dommageable.

Ceci est une grosse affaire.


1
Qu'entendez-vous par contraction?

4
@ Egg: Parfois, quand je travaille, je peux être complètement détendu et très productif. Pendant mes mauvais jours, je cours sur l'adrénaline et la caféine et je ressens une tension énorme dans mon corps. Si je fais très attention, je contracte effectivement des muscles. Je remarque cette tension chez les autres tout le temps. Malheureusement, cela peut entraîner toutes sortes de problèmes, tels que l'épuisement professionnel et les maladies cardiaques, ainsi qu'une perte nette de productivité car il n'est possible de sprinter que pour une durée limitée. C'est la contraction dont je parle.
Brian MacKay

@ Egg, il signifie contraction des muscles inutilisés.

2
En parlant de café et de contraction, saviez-vous que le café rétrécit l’artère qui fournit le sang au cerveau? Cela provoque le cerveau à se réveiller. Le café n'est pas une si bonne chose après tout. tl; dr boire de l'eau
Reno

83

Type de données de base et théorie des algorithmes. Des choses comme la notation Big O, les tableaux, les files d'attente, etc.


Ne vous aide pas du tout si vous ne faites que créer des modèles pour les systèmes de gestion de contenu Web.

3
De nos jours, des algorithmes standard sont implémentés dans les bibliothèques / frameworks, mais je suis d'accord pour dire qu'il est utile de penser à un algorithme rigide, mais pas très souvent

7
Ce n’est pas parce qu’elles sont déjà implémentées que vous n’avez pas à comprendre quoi utiliser, quand la complexité est garantie, etc. C’est l’essentiel des algorithmes.

3
D'accord avec Greg Rogers. Vous devrez peut-être implémenter les algorithmes, mais vous comprendrez mieux leurs complexités et leurs compromis. Par exemple. Certains algorithmes utilisent plus de mémoire mais sont plus rapides.

6
Vous ne saurez pas lequel utiliser si vous ne les comprenez pas. Les algorithmes sont très importants.

60

Comment choisir le bon outil pour la bonne tâche, et ne pas participer à des guerres enflammées sur ses outils de programmation préférés.


+1 pour que celui-ci ne reste pas à 42 :)
CharlesB

54

Eh bien, voici mon 0,02 $:

  • L'apprentissage ne s'arrête jamais. Même si vous pensez bien être, il y a toujours quelqu'un de meilleur que vous et il y a toujours quelque chose que vous pouvez améliorer sur vous-même. Si vous arrêtez d'apprendre, vous vous dégraderez inévitablement en tant que programmeur. Lire des livres. Lire des blogs. Parlez à d'autres programmeurs.
  • Essayez d'apprendre plusieurs langues. Au moins l'un d'entre eux est orienté objet. De plus, vous devriez connaître quelques technologies liées au langage que vous apprenez (par exemple, si vous apprenez Java, ce serait bien si vous connaissiez quelque chose sur Spring, etc.).
  • Refactoring. Tôt ou tard, vous aurez besoin de cette connaissance.
  • Apprenez à gérer le code hérité.
  • Ecrire des tests unitaires. En savoir plus sur TDD.
  • Apprenez à travailler en équipe.
  • Écrivez un code élégant et lisible. Comme le dit le vieil adage: "Ecrivez votre code comme si la personne qui va le conserver est un tueur en série psychotique qui sait où vous habitez."
  • Apprenez à être paresseux et discipliné en même temps. Les bons programmeurs possèdent ces deux qualités. Aussi étrange que cela paraisse, ils ne sont pas contradictoires, mais complémentaires.

Est-ce que votre 0,02 dollars ou 0,02 cents? LOL! :-D

"Ecrivez votre code comme si la personne qui va le conserver est un tueur en série psychotique qui sait où vous habitez." +1
Ben

50

Vous ne pouvez pas tester la qualité d'un produit.


2
Ainsi, les professionnels de "l'Assurance qualité" portent le mauvais nom.

1
Techniquement parlant, QA et Test ne sont pas la même chose, bien que je ne sois pas sûr que la plupart des organisations pratiquent réellement la différence.
Tall Jeff

5
Récemment rencontré - et bloqué: "Le résultat des tests n’est pas la qualité, mais la connaissance".
peterchen

richdiet: L'expert de la SQA, James Bach, estime que le "A" de SQA / QA devrait signifier "Assistance". Je suis tout à fait d’accord avec son opinion et votre déclaration.

44

Chaque programmeur doit comprendre les modèles de conception .


13
J'ajouterais qu'ils ont également besoin de comprendre que tout ne peut pas être fabriqué dans un modèle de conception donné.
tloach

10
J'ajouterais également que tous les programmeurs ne doivent pas comprendre les modèles de conception. Il existe des langues dans des pays lointains qui possèdent d'autres fonctionnalités si puissantes que la pensée découle directement du programmeur et devient un programme fonctionnel. Dans ces langues, les schémas délibérés sont une mauvaise direction.
Ali

2
les motifs de conception sont destinés aux dessinateurs et non aux "programmeurs" - le programmeur aura besoin de savoir que lorsqu'il / elle devient un "concepteur"

10
Il existe deux types de personnes: les personnes qui aiment coder et celles qui préfèrent parler de codage. Les modèles de design sont un must pour le deuxième groupe ..
Bjorn Reppen Le

1
De tels modèles sont un moyen de surmonter les limites des langues. Un programmeur ne doit les comprendre que parce qu'il doit comprendre et pouvoir surmonter les faiblesses de ses langues.

44

Je suis un peu en retard à celui-ci, mais je vais aller avec les connaissances énoncées par Edsger Dijkstra:

Outre une inclination mathématique, une maîtrise exceptionnelle de sa langue maternelle est l'atout le plus essentiel d'un programmeur compétent.

Si vous ne pouvez pas écrire un bon paragraphe, il est probable que vous ne pouvez pas écrire un bon code non plus.


8
Pourtant, je suis émerveillé par la terrible orthographe, la grammaire et la ponctuation utilisées par certains programmeurs pour écrire en langage naturel. On pourrait penser que travailler tous les jours avec des systèmes à tolérance zéro pour les fautes d'orthographe et une syntaxe invalide aurait un effet bénéfique ...

1
@cheduardo, c'est parce qu'une fois que vous compilez ou exécutez un programme, dans la plupart des langues, vous serez informé de toute erreur d'orthographe, de grammaire ou de ponctuation, qui peut ensuite être facilement corrigée. Pas si pour les erreurs logiques.
Inshallah

@Inshallah: sauf si vous faites quelque chose comme if (BlowUpTheSystem = 1). Accordé, si les tests unitaires sont corrects, vous ne gagnerez probablement que du temps. Mais alors le temps est assez important.
Intuité le

2
D'accord ... hmm ... sans la partie "langue maternelle", certains d'entre nous [malheureusement?] Communiquent mieux / plus clairement dans nos langues non autochtones.

39

Ne vous investissez pas trop émotionnellement dans une technologie, un système d’exploitation ou une langue donnée, ne vous attachez pas à une religion ou n’êtes pas religieux - aucune d’entre elles n’est parfaite - à long terme, vous voudrez peut-être créer votre propre carte comme à propos de chaque différent.

Pensez-y comme aux voitures - vous n’avez peut-être jamais conduit une voiture en particulier, mais elles ont toutes des clés, des volants, des accélérateurs et des freins - vous devriez pouvoir y entrer et en partir rapidement une fois que vous avez déterminé où. Traitez les systèmes d'exploitation et les langues de la même manière et concentrez-vous sur l'apprentissage des concepts essentiels qui les sous-tendent, même si vous êtes au cœur des spécificités d'un cas donné.

Et au fil du temps, essayez de comprendre et d’apprécier l’ascendance, le patrimoine et les points communs des différentes technologies qui vous aideront à garder la perspective. Sachez par exemple que, même si l’arbre évolutif est en train de se ramifier et de se retrouver dans des impasses, la technologie a tendance à converger de manière répétée autour des "meilleures pratiques" et des "économies d’échelle" ( par exemple, notez qu'un Mac n'est pas si différent d'un PC sous le capot ces jours-ci ...).

Enfin, rappelez-vous que peu importe le plaisir que vous ressentez avec tout cela, la technologie représente essentiellement un objectif imparfait entre ce que votre esprit peut envisager et ce que vous produisez réellement. Faites de votre mieux, apprenez à apprendre et restez adaptable ...



35

Que le jour où vous arrêtez d'apprendre devrait être le jour où vous n'êtes plus programmeur.


Si j'avais un souhait, ce serait que le Père Noël était mon père.

Parce que le père Noël

1
Le jour où vous arrêtez d'apprendre devrait être le jour de votre mort. :) +1 de toute façon
ShdNx

Donc, pour vivre éternellement, vous devez toujours continuer à apprendre? Maintenant, il y a une idée que je peux approuver!
canadiancreed

34

Tests unitaires et débogage.


Le premier supprime le besoin du second. ;-)

4
Non, lorsque le test unitaire échoue, cela nécessite un débogage. Les deux vont ensemble.
Zan Lynx

Je ne saurais trop insister là-dessus.
fastcodejava

33

Cela a déjà été mentionné mais je pense que cela mérite sa propre réponse.


Je rencontre de plus en plus d’utilisations, et je ramasse des morceaux ici et là, mais je ne suis même pas un amateur.

Je suis complètement d'accord. Cela semble étrange et difficile lorsque vous ne le comprenez pas, mais lorsque vous le comprenez, c'est tellement plus facile qu'une tonne d'appels de fonction sous-chaîne / indexof qui seraient nécessaires pour faire la même chose autrement. Je voudrais juste m'assurer que vos modèles sont bien commentés.
Kibbee

9
Certaines personnes, confrontées à un problème, pensent "Je sais, je vais utiliser des expressions régulières." Maintenant, ils ont deux problèmes. - "Jamie Zawinski": jwz.livejournal.com , dans comp.lang.emacs
Bjorn Reppen le

Utiliser un éditeur essentiellement construit autour d’eux est un bon moyen d’apprendre le méchant Nitty Gritty. Mon expérience concerne vim (qui utilise un équivalent comparable à celui des PCRE standard de facto), mais j’ai l’impression que les mêmes règles s’appliquent dans le monde emacs.
Intuitionné le

1
Certaines personnes, confrontées à une expression régulière, se disent: «Je sais, je citerai Jamie Zawinski.» Maintenant, elles ont deux problèmes (l'une d'entre elles est qu'elles ne savent probablement pas ce qu'elles font en premier lieu). .
Donal Fellows

29

Personne ne veut utiliser un logiciel. Ils veulent des problèmes résolus.


7
Exactement. Lorsque j'entends des développeurs tenter d'expliquer la base de données à un utilisateur final pour répondre à la question de savoir pourquoi quelque chose ne peut pas être fait, je craque. Ils n'ont pas besoin de savoir comment nous faisons les choses. Ils veulent juste que ça marche. Et c'est comme ça que ça devrait être.
Kevin Fairchild

J'aime croire que l'on pourrait écrire des logiciels que les gens trouveront un plaisir à utiliser.

Je ne pourrais pas être plus d'accord. Cela s'applique toutefois également aux API. Personne ne veut apprendre de nouvelles API parce que c'est tellement drôle. Nous voulons la fonctionnalité de l'API, pas le code qu'elle représente.
Blub

Kevin, je souhaite que notre "programmeur de mise en œuvre" (mot chic pour testeur) puisse lire et comprendre cela. Moi aussi, je suis assis derrière mon bureau, espérant que le monde l'engloutira lorsqu'il commence à parler de boucles et de déclarations éventuelles à l'intention des utilisateurs finaux.

27

Coffee et IntelliSense sont vos meilleurs amis.


J'aimerais pouvoir donner plus d'un vote positif!
Dinah

J'espère avoir plus de café !!!! ñ_ñ

Je pense que je suis d'accord avec cela plus que toute autre chose sur SO.
Unkwntech

Je ne bois pratiquement jamais de café sauf si j'ai absolument besoin de terminer un projet en X heures, quand: Nombre d'heures utilisées + X> 8 par jour.
Blub

Le café ne vous donne aucune énergie. Il suffit d’en tirer une partie de vos réserves internes. C'est mauvais / malsain.
Andrei Rinea

18

Comment observer un gros objet compliqué et le décomposer en petits objets simples qui accomplissent toujours la même tâche quand ils sont à nouveau assemblés.


18

Ne faites jamais confiance à un utilisateur ( surtout si l'application est publique!), Ils feront souvent tout ce qui est en leur pouvoir pour détruire votre application d'une manière ou d'une autre.

Préparez-la pour l'avenir et pour qu'elle soit extensible - vous ne savez jamais quand vous souhaitez l'étendre dans quelques années et vous réalisez combien d'effort il faudrait pour recoder le code mal créé.


1
C'est trop généralisé. Un peu de pragmatisme est bien aussi.
Mafu

18

Le programmeur ne sait pas tout et doit toujours essayer d'apprendre de nouvelles langues / technologies, etc.


16

Les bases d'une bonne conception d'interface utilisateur et de design de communication (ou graphique) .

Je vois tellement d'applications et de projets ruinés par un design médiocre ou une utilisation peu aisée. Le simple fait d’apprendre les bases peut faire toute la différence. De plus, les techniques de résolution de problèmes visuels (c.-à-d. Comment communiquer visuellement un concept) constituent un défi stimulant qui devrait vous ouvrir les yeux sur de nouvelles façons de voir, ce qui à son tour devrait avoir un impact sur votre code.

Un livre recommandé est le livre de conception de The Non-Designer de Robin Williams

Voici ce que Joel Spolsky en dit :

Hou la la! Tout le monde doit faire un peu de graphisme et chaque équipe de logiciels n’a pas le luxe des designers professionnels. Cet excellent livre mince vous donnera une idée des principes de la mise en page, des polices, etc. La bonne nouvelle est que vous pouvez le lire dans le bain avant que l’eau ne refroidisse, et le lendemain, vos boîtes de dialogue les pages Web commenceront à être meilleures.


1
J'ajouterai cela à un signe supplémentaire de "conception des choses de tous les jours". amazon.fr/Design-Everyday-Things-Donald-Norman/dp/0385267746
Stimul8d

14

Chaque programmeur doit savoir apprendre rapidement. Souvent, vous entrez dans un emploi et on vous demandera de développer une technologie que vous n’avez jamais utilisée. Ils pourraient vous donner environ une semaine pour vous mettre sur pied (si vous êtes chanceux) avant de vous demander d'écrire un code de qualité production.


J'ai commencé mon premier travail de programmation et en moins d'une semaine, j'écrivais du code qui serait éventuellement mis en ligne. Heureusement, j'apprends vite et j'ai une expérience de programmation passée. En moins de 6 mois, j'avais restructuré la connexion client-serveur pour améliorer les performances de trois fois. C'était dans une langue que je n'avais jamais utilisée auparavant.

14

Contrôle de version. Et pour citer ma petite amie: "Je ne veux pas seulement que tu fasses la vaisselle, je veux que ça te plaise !"



10

Du haut de ma tête:

  1. Très peu de problèmes de programmation nécessitent des calculs autres que les additions, les soustractions, les multiplications et les divisions. Si vous envisagez d'utiliser le calcul pour résoudre un problème, recherchez-le de manière exhaustive avant de le faire.

  2. Chaque fois que vous vous demandez comment quelque chose devrait fonctionner, vous le faites mal. Ce n'est pas votre travail d'être télépathique.

  3. La personne qui vous donne les spécifications sait rarement tout ce qu'il veut jusqu'à ce que vous l'ayez résolue.

  4. Plus de la moitié de la qualité de programmeur provient des relations avec les êtres humains. Interagir avec votre équipe, gérer votre responsable et affiner l'utilisateur final sont la moitié du travail.

  5. Un bon code est écrit pour être lu par les gens autant que pour votre compilateur.

  6. La meilleure pratique et la réalité pratique seront en conflit plus que ne le pense le programmeur, mais moins que le gestionnaire. Quand ils semblent être en conflit, c'est à vous de définir et de comprendre le conflit, puis de céder à la pratique. La solution subtile et intelligente n’est meilleure que la solution laide et brutale si elle est plus rentable à long terme.

  7. Les bons outils ne peuvent pas faire de bons programmeurs, mais les mauvais outils nous rendent tout aussi affreux.

  8. Ne méprisez jamais une technologie, mais cherchez toujours la meilleure alternative.

  9. Plus vous connaissez de langues, mieux vous maîtriserez celle que vous utilisez.

  10. Ne soyez pas dérangé par la lente progression des pensées orientées vers la programmation dans votre vie quotidienne. Même lorsque nous ne sommes pas près d'un ordinateur, nous souffrons tous de limitations de bande passante, de performances liées à la commutation de tâches et nous devons charger des éléments à partir du stockage de sauvegarde. Les ordinateurs sont supposés imiter la pensée humaine et les analogues sont partout.


Le numéro 10 m'a fait rire. Tant de fois je vais travailler sur un problème au travail mais ce n'est qu'au lit à 22 heures que je finis par trouver la réponse!

9

Lire le code des autres ne va pas gâcher votre cerveau, mais plutôt comprendre pourquoi vous ne l'auriez pas fait de cette façon (si mieux ou pas, c'est une autre question).

Cela vous donne la programmation expérience gedankenexperiment , et parfois vous trouvez quelqu'un implémentant quelque chose de bien meilleur! J'aime beaucoup mieux.

Cette réponse s'étend naturellement à la lecture de votre propre code, elle utilise donc le contrôle de version et le format DIFF, et donc 42.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.