Étant donné que les programmeurs sont des auteurs et écrivent du code pour exprimer des pensées et des concepts abstraits, et qu'un bon code devrait être lu par d'autres programmeurs sans difficultés et malentendus, un programmeur devrait-il prendre des leçons d'écriture pour écrire un meilleur code?

Abstraire des concepts et des problèmes / entités du monde réel est une partie importante de l'écriture d'un bon code, et une bonne maîtrise du langage utilisé pour le codage devrait permettre au programmeur d'exprimer ses pensées plus facilement ou mieux. En outre, lorsque vous essayez d'écrire ou de réécrire du code pour l'améliorer, vous pouvez consacrer beaucoup de temps à décider des noms des fonctions, des variables ou des structures de données.

Je pense que cela pourrait également aider à éviter d'écrire du code avec plusieurs sens, souvent à l'origine de malentendus entre différents programmeurs. Le code doit toujours exprimer clairement sa fonction sans ambiguïté.

1. Écrire des leçons? Pas vraiment.

L'écriture du code source est suffisamment différente de l'écriture d'un livre.

Alors que les deux poursuivent les mêmes objectifs: être aussi clairs que possible et faciles à comprendre, ils le font d'une manière très différente, et les choses qu'un écrivain devrait apprendre ne sont pas les mêmes que celles qu'un développeur de logiciels devrait apprendre.

Exemple 1: figures de style

Les figures de style sont précieuses lors de l'écriture de romans, de poésie, etc., car elles augmentent l'expressivité de l'écriture.

Quelle est la dernière fois que vous avez vu un oxymore ou des litotes dans le code source ? Serait-il utile de les avoir, ou serait-il plutôt extrêmement nocif pour tout développeur qui devra conserver ce code source plus tard?

Exemple 2: vocabulaire

Un vocabulaire riche est très apprécié dans la littérature. Le vocabulaire de William Shakespeare, par exemple, est de vingt mille à vingt-cinq mille mots. Un vocabulaire plus riche rend la lecture d'un roman ou d'un poème plus intéressante.

Lorsque vous écrivez du code source, vous vous attendez à ce qu'il soit lu par des personnes qui ne parlent pas très bien anglais . Montrer à quel point vous savez que l'anglais serait extrêmement dangereux pour votre code. Si vous connaissez un mot de fantaisie qui signifie exactement ce dont vous avez besoin mais que vous savez que beaucoup de gens ne connaissent pas le sens de ce mot, vous devriez plutôt trouver un synonyme moins expressif ou un ensemble de mots qui expliquent le sens. Un vocabulaire de quelques milliers de mots est souvent largement suffisant pour un projet donné.

Notez un aspect important: bien que Google Translate puisse être d'une grande aide pour un locuteur non natif, il y a deux problèmes avec n'importe quel traducteur:

• Une paire de langues n'a pas nécessairement une correspondance 1: 1 entre les mots. Certains mots n'ont pas de traduction dans d'autres langues ou plusieurs mots peuvent se traduire en un seul mot dans une langue étrangère. Par exemple, en russe, il y a une énorme quantité de mots qui ciblent des états spécifiques de neige et de temps froid, et leur traduction en français ou en espagnol est généralement impossible sans perdre leur spécificité.

• Un mot a parfois plusieurs sens, et le sens est déduit du contexte. Google Translate, malgré sa haute qualité, n'est généralement pas en mesure d'indiquer la signification de toutes les situations, sauf les plus élémentaires.

Exemple 3: expressions

Les expressions enrichissent également la prose. Un auteur s'attend à ce qu'un lecteur ait une quantité donnée de culture générale et utilise cette opportunité pour rendre le texte plus expressif.

De même que dans l'exemple précédent, de telles expressions peuvent être très problématiques lorsqu'elles sont lues par des personnes qui ne sont pas de langue maternelle. Mais si le vocabulaire général peut généralement être traduit, les expressions sont beaucoup plus problématiques.

Par exemple, l'anglais n'est pas ma langue maternelle, et au quotidien, je rencontre des expressions, y compris ici sur StackExchange, que je ne connais pas. J'essaie de deviner leur signification, et parfois j'ai raison. Mais parfois, je me trompe, et googler ces expressions n'aide pas.

Un utilisateur dans son commentaire m'a rappelé un exemple qui m'a fait souffrir longtemps quand je viens de commencer la programmation: l' aiguille et la botte de foin de PHP . Je n'étais pas au courant de la figure de style correspondante, donc à chaque fois que je lisais la documentation, je me demandais de quoi il s'agissait. Inutile de dire que les C # sequence.Contains(element)ou les excellents Python element in sequencesont une bien meilleure alternative. Eh bien, au moins, les développeurs qui ne connaissent pas l'hébreu devaient également souffrir de PHP , mais c'est une autre histoire.

Exemple 4: références culturelles

Références culturelles. En littérature, il est tentant d'inclure des éléments d'une culture donnée, et cela aussi rend le livre plus riche et parfois plus intéressant à lire.

Cependant, le code s'adresse aux développeurs du monde entier. Par conséquent, ce qui est une référence évidente pour un développeur italien peut ne pas être aussi évident pour un développeur russe, et ce que tout garçon ou fille indien sait ne peut pas nécessairement être connu par un programmeur américain.

Le même utilisateur qui a parlé de l'aiguille et de la botte de foin a également donné un excellent exemple d'une telle référence culturelle: le Graal. Qui ne sait pas ce qu'est le Graal? Enfin, je veux dire, c'est "Graal" en français, "Grial" en espagnol et ... "Kutsal Kâse" en turc, mais quand même. Cependant, combien de développeurs américains ou européens connaissent l'histoire médiévale de la Chine ou de l'Inde? Pourquoi est-ce que quelqu'un supposerait que chaque programmeur chinois et indien doit connaître la référence Holy Graal?

2. Des leçons pour écrire du code source expressif? Sûr.

• Tout développeur doit apprendre à écrire du code source expressif.

• Tout développeur doit expliquer pourquoi le commentaire dans:

  int j = i + 1; // Creating i and adding 1 to it.
  

  est mauvais, même à part le fait que c'est totalement faux.

• Tout développeur doit être capable de comprendre le refactoring de base et comment il aide à rendre le code source plus expressif.

• Tout développeur doit se rappeler que 20% du temps est consacré au développement du code et 80% du temps à le maintenir. Pour certains projets, cela ressemble plus à 5% - 95%.

• etc.

En substance, la programmation est proche de la documentation technique. Une personne qui écrit une fiche technique pour un boulon doit-elle prendre des leçons d'écriture? Pas vraiment. Il en va de même pour les développeurs. N'importe qui devrait écrire sans faire de fautes d'orthographe dans chaque mot, et n'importe qui devrait être capable de communiquer ses idées suffisamment clairement. En dehors de cela, je ne sais pas comment la rédaction de leçons serait plus utile que, disons, un cours d'informatique ou de sécurité informatique ou autre.

L'expressivité du code source peut être apprise par d'autres moyens. superM en a mentionné un dans sa réponse : lire un bon code. Je peux en mentionner quelques autres:

• Lire des livres comme Beautiful Code ou Code Complete,

• Demander à un développeur plus expérimenté d'examiner votre code,

• Comprendre les modèles et comment et quand les utiliser.

un programmeur devrait-il prendre des leçons d'écriture pour écrire un meilleur code?

Non. Un programmeur devrait prendre des leçons d'écriture pour apprendre à écrire une meilleure prose. Un programmeur devrait prendre des leçons de programmation pour apprendre à écrire un meilleur code. Malgré certaines similitudes, l'écriture de prose et l'écriture de code sont très différentes.

Cela ne veut pas dire que les programmeurs ne devraient pas prendre de cours d'écriture. Ils devraient! Certaines raisons:

• L'écriture est une compétence essentielle pour toute personne instruite. Vous aurez l'air plus intelligent si vous savez bien écrire.

• Malgré tous leurs efforts, les programmeurs ont souvent besoin de communiquer avec d'autres humains, souvent en utilisant le mot écrit.

• Vous apprenez des compétences au-delà de l'écriture dans les cours d'écriture, et celles-ci sont souvent utiles aux programmeurs. Par exemple, vous apprendrez à discuter du travail des autres sans blesser leurs sentiments, et vous apprendrez à accepter les critiques des autres sans les prendre personnellement.

Mon code dépend de plus en plus de la création d'un vocabulaire partagé entre l'entreprise et les équipes techniques. Je dirais que l'amélioration de vos compétences en rédaction peut vous aider à réduire l'ambiguïté et les malentendus dans ces efforts, mais que cela n'aidera probablement pas l'expressivité de votre code.

La notion littéraire d'expressivité n'est pas la même que la notion de programmation d'expressivité. Dans de nombreux cas, l'ambiguïté de la langue peut être utilisée comme un dispositif littéraire, même dans des ouvrages non romanesques, sous une forme qui augmente l'expressivité, car elle déclenchera diverses associations culturelles, linguistiques et symboliques chez le lecteur, à la fois intentionnelles et non intentionnelles. Ce type d'expressivité n'est pas souhaitable dans la programmation; l'abstraction a plus de valeur que l'ambiguïté. En programmation, l'abstraction augmente la flexibilité avec peut-être un certain coût de charge cognitive. L'abstraction sous forme littéraire peut avoir le contraire de l'effet qu'elle a dans la programmation: plus votre écriture est abstraite, plus le lecteur aura probablement l'impression que vous ne dites rien. Tous ces symboles et associations qui résultent d'un discours concret ont une valeur,

Cependant, un programmeur n'est pas une machine. Les humains bénéficient de manière souvent inattendue de la croissance intellectuelle et émotionnelle. L'amélioration de votre écriture peut entraîner une plus grande empathie client parce que vous vous forcez à lutter contre des problèmes de communication; peut-être ressentirez-vous ce client qui dit ce qu'il veut, puis vous le livrez et il se rend compte que ce n'est pas ce dont il a besoin. Peut-être que vous apprendrez simplement à vous concentrer sur ce qui n'est pas dit.

Peut-être qu'apprendre à lancer de l'argile sur un tour de potier vous aidera à commencer à voir des parallèles entre l'artisanat et le développement de logiciels. L'étude de la façon dont les architectes du bâtiment communiquent peut vous amener à avoir une meilleure appréciation de la construction d'un vocabulaire de modèles de conception en programmation. L'étude de la biologie pourrait vous conduire à des idées fascinantes sur la façon dont les fourmis et les abeilles trouvent et communiquent sur les sources de nourriture et comment ces mécanismes simples pourraient être traduits en algorithmes de recherche de chemin.

Apprendre des choses en dehors de votre domaine principal vaut la peine car les personnes curieuses font de meilleurs développeurs que les autres.

Pour ce que ça vaut, j'étais presque un major en littérature; J'ai fini par passer aux études est-asiatiques parce que j'étais plus intéressé par les cours que je suivais dans ce département. Il y a une chance que je ne sois pas dans l'industrie si je n'avais pas étudié les études d'Asie de l'Est, car l'effet secondaire de l'étude du japonais m'a rendu plus précieux à l'époque, quand une société de logiciels m'a embauché en partie en raison de mes compétences linguistiques. Je devais encore construire un portefeuille plus profond de compétences techniques, mais les effets secondaires imprévus de l'apprentissage de tout peuvent faire de vous un professionnel du logiciel meilleur et plus pertinent.

Lorsque les projets de programmation échouent, cela est généralement dû à une communication défaillante, généralement autour des exigences. Bien qu'une connaissance médiocre de l'anglais puisse être suffisante pour réellement écrire du code, être un bon communicateur est essentiel pour écrire le bon code. À l'ère du télétravail et de la communication textuelle, l'écriture anglaise est une compétence de communication très importante.

Cela dit, votre question est écrite de manière très claire et concise - mieux que la plupart des programmeurs avec qui j'ai travaillé. N'ayant pas vu votre code, je vous suggère de vous concentrer sur votre expression dans le langage de codage de votre choix. Pour Java, je recommande le livre de Joshua Bloch, "Effective Java".

Comme les écrivains apprennent à lire les classiques du monde, les programmeurs sont éduqués en lisant du bon code. Mais il y a un petit problème. Bien qu'il existe des géants reconnus dans la littérature, il y en a peu dans la programmation. Et s'il y en a, ils pourraient «parler» une langue différente. (Je ne suis même pas sûr qu'il soit raisonnable de conseiller la lecture du code source Minix par Tanenbaum)

Il existe de nombreuses façons populaires de rendre le code plus lisible (=> maintenable), comme écrire des commentaires, donner des noms significatifs, etc. En outre, de nombreuses entreprises établissent leurs règles d'écriture de code, et cela rend tout beaucoup plus facile.

Quoi qu'il en soit, comme beaucoup d'excellents écrivains, les programmeurs ne sont jamais satisfaits de leur propre code. Il est donc aussi important de savoir quand s'arrêter que d'écrire du code de qualité.

Je trouve toujours simplement s'arrêter après chaque bit de code que vous écrivez et le relire, en imaginant que vous ne l'avez jamais vu auparavant, cela me permet de faire un long chemin avec cela.

Encore mieux est de demander à un ami qui connaît la programmation de lire votre code sans lui dire ce qu'il fait.

Je ne pense pas que cela aidera; l'écriture créative concerne les intrigues, le développement de personnages et le dialogue, pas l'expression de clartés techniques. La rédaction technique peut aider, mais j'en doute - ce sont juste des types d'écriture très différents!

et notez que le code "lisible" est subjectif, et principalement une question de style syntaxique et d'idiomes communs (qui varient selon les langues et même entre les équipes)

cependant, il est important de choisir de bons noms pour les variables, les classes et les méthodes. Chaque développeur devient, dans une certaine mesure, un expert en la matière dans certains aspects du domaine en développement, il est donc essentiel d'utiliser correctement la terminologie du domaine.

les examens par les pairs peuvent vous aider à développer le vocabulaire et la confiance

Il y a certainement une grande différence entre écrire du code et écrire de la prose.

En prose, les phrases sont connectées (ou séparées) par le temps (la façon dont elles se succèdent pour atteindre une fin ou un sens) mais en code (efficace), vous pouvez (re) charger des parties de `` l'histoire '' à partir de tableaux avec des répétitions actions / réponses. Ainsi, l'interaction avec le lecteur (en prose) ou l'utilisateur (de code) est totalement différente.

D'une autre manière, écrire de la "belle" prose et écrire du "joli" code sont similaires: apprendre à écrire (code ou prose) est un processus qui implique beaucoup d'erreurs (ou de penser / tester des améliorations, ou de reformuler) pour l'obtenir " élégant'.

Je pense que le système chimique périodique des éléments est élégant, en raison de la manière très compacte qu'il décrit certaines propriétés fondamentales des matériaux de base que nous utilisons, un peu comme un code efficace mais ce n'est certainement pas de la prose. Une blague a beaucoup de qualités en prose (vous mettre dans une certaine humeur, la garder et la changer, quand elle est inattendue), mais c'est une pratique de codage épouvantable.

Mais les deux types d'écriture demandent de l'artisanat.

L'anglais de base et la grammaire sont suffisants pour un programmeur de mon point de vue. Mais alors, toute chose pour briser une routine de programmation monotone sera toujours rajeunissante et donc les leçons d'écriture seront relaxantes pour les programmeurs.