Que devraient savoir tous les programmeurs sur la programmation?

52

S'il vous plaît, restez sur les questions techniques , les comportements à éviter, les questions culturelles, politiques ou de carrière.

experience self-improvement programming-practices

— bigown
source

7

Voyez également ceci stackoverflow.com/questions/132798/…

— pramodc84

Ce genre de question m'énerve vraiment. Cela ne peut venir que de l'esprit de quelqu'un qui voit le monde en noir et blanc. Tous les programmeurs n’ont pas le même travail et s’il s’agit du plus petit dénominateur commun que vous recherchez, les réponses ci-dessous montrent que vous vous retrouvez avec une liste de bêtes noires.

— Capitaine Sensible

92

Le bogue est dans votre code, pas le compilateur ou les bibliothèques d'exécution.
Si vous voyez un bogue qui ne peut pas arriver, vérifiez que vous avez correctement construit et déployé votre programme. (Surtout si vous utilisez un environnement de développement IDE ou de compilation complexe qui essaie de vous cacher les détails compliqués ... ou si votre compilation implique de nombreuses étapes manuelles.)
Les programmes simultanés / multi-tâches sont difficiles à écrire et à tester correctement. Il est préférable de déléguer autant que possible les librairies et les frameworks d'accès concurrentiel.
La rédaction de la documentation fait partie de votre travail de programmeur. Ne le laissez pas à "quelqu'un d'autre".

MODIFIER

Oui, mon point n ° 1 est surestimé. Même les plates-formes d'applications les mieux conçues ont leur lot de bogues, et certaines des moins bien conçues en sont très répandues. Mais même, vous devriez toujours soupçonner votre code d' abord , et commencer à blâmer seulement compilateur / bugs bibliothèque lorsque vous avez clairement la preuve que votre code est pas en faute.

À l'époque où je développais le C / C ++, je me souviens de cas où de supposés "bogues" d'optimiseur se sont avérés être dus à mon expérience (ou à celle d'un autre programmeur) qui avait déjà fait des choses dont les résultats sont indéfinis. Cela s'applique même aux langages supposés sûrs comme Java; par exemple, examinez de près le modèle de mémoire Java (chapitre 17 de JLS).

— Stephen C
source

17

Je préfère dire "Le bogue est probablement dans votre code", car j'ai rencontré plusieurs fois des bogues dans les bibliothèques d'exécution. Je n'ai pas encore rencontré de bogue de compilation. +1 quand même.

— Chinmay Kanchi

29

Si vous n'avez jamais trouvé de véritable bogue dans le compilateur, vous n'êtes pas assez aventureux avec votre codage. ;)

— Mason Wheeler le

8

@Chinmay, @ spudd86, @Mason - oui ... et j'ai également trouvé ma part de bugs liés au compilateur et à la bibliothèque au cours de mes 30 ans de programmation. Mais selon mon expérience, plus de 99% des bogues s'avèrent être (du moins en partie) la faute de mon code. Ma réponse exagère volontairement ceci pour faire comprendre que vous devriez toujours suspecter votre code en premier.

— Stephen C

5

Je ne comprends pas la peur irrationnelle que les gens ressentent avec la programmation multithread. Je suppose que les personnes qui perpétuent ce point de vue ne programment pas beaucoup de code multithread. C'est juste pas si difficile. +1 pour tout le reste cependant.

— Steven Evers le

4

Si vous travaillez sur le compilateur, le bogue est probablement à la fois dans votre code et dans le compilateur;)

— Legooolas

84

Comment lire le code des autres
Le code n'existe pas s'il n'est pas vérifié dans Version Control System.

— pramodc84
source

8

+10000 si je pouvais pour le commentaire de contrôle de version. L’historique et la journalisation des modifications sont absolument indispensables et sont la raison pour laquelle vous devez tout mettre dans le contrôle de version dès le début.

— Legooolas

2

... et le référentiel a été synchronisé sur au moins un autre emplacement. Important avec DVCS, mais aussi avec VCS centralisé.

D'ailleurs, le code n'existe pas, sauf s'il existe un élément de travail qui autorise le développeur à l'écrire.

— Jesse C. Slicer

2

Je vais plus un pour apprendre à lire le code des autres. C'est plus difficile que la plupart d'entre nous réalisons, mais c'est un élément essentiel d'une programmation réussie.

— Bogeymin

plus un pour apprendre à lire le code des autres.

— itsaboutcode

76

Les calculs en virgule flottante ne sont pas précis.

— Chinmay Kanchi
source

22

+1: Ce que tout informaticien devrait savoir sur l'arithmétique en

— virgule

Si quelqu'un ne sait pas de quoi je parle, lisez le lien de @ Adam. C'est un excellent résumé des pièges du calcul en virgule flottante.

— Chinmay Kanchi

1

Et s'ils ne le savent pas, ils peuvent faire partie du groupe de personnes qui posent quotidiennement des questions sur stackoverflow.

— Brian R. Bondy

1

@ Brian: Si vrai. J'aimerais qu'il y ait un moyen d'identifier les questions expliquées par l'arithmétique en virgule flottante. Vous pouvez créer une application Stack qui affiche chaque jour une question différente en virgule flottante!

— Adam Paynter le

63

N'arrête pas d'apprendre.

— systempuntoout
source

1

Connexes: Ne cessez pas de croire.

— Fishtoaster

3

Connexes: Ne cessez pas de penser à demain.

— octobre

7

Connexes: n'arrêtez pas la musique.

— Adam

1

Connexes: n'arrêtez pas de bouger! C'est ta vie, continue à avancer, bien faire les choses, il faut bien faire les choses!

— octobre

44

Réduire la duplication est la première chose que vous puissiez faire pour améliorer la qualité et la maintenabilité de votre code.

— Chris Holmes
source

4

SEC, oui! Comment puis-je oublier? ;-)

— Maniero

C’est tellement important que j’y ai répondu à nouveau .

Je dirais plutôt: RÉDUIRE LES CONDITIONNELS. Chaque while / if / for est un bug potentiel.

— Zvrba

1

Vous savez, ce qui est drôle avec DRY, c’est que ça se répète partout. :) +1

— Billy ONeal le

39

Compétences de dépannage et de débogage

Ils ne consacrent guère de temps à ce sujet dans les cours de programmation que j'ai suivis et, d'après mon expérience, c'est l'un des facteurs les plus déterminants de la productivité d'un programmeur. Qu'on le veuille ou non, vous passez beaucoup plus de temps dans la phase de maintenance de votre application que dans la nouvelle phase de développement.

J'ai travaillé avec tellement de programmeurs qui déboguent en changeant des choses de manière aléatoire, sans stratégie pour trouver le problème. J'ai eu cette conversation des dizaines de fois.

Autre programmeur: Je pense que nous devrions essayer de voir si cela résout le problème.
Moi: D'accord, en supposant que ça règle le problème. Qu'est-ce que cela vous dit sur la source du problème?
Autre programmeur: Je ne sais pas, mais nous devons essayer quelque chose .

— JohnFx
source

2

J'étais sur le point de poster ceci. Une grande partie du travail du programmeur consiste à corriger les bogues et beaucoup de gens ont tendance à être incapables de le faire (en particulier dans le code des autres).

— Dov

+1, je suis passé de javascript / php à C # et suis tombé en amour avec le code. Je souhaite que les langages à typage dynamique fassent un bien meilleur travail dans ce domaine.

— Evan Plaice

Un autre comportement étrange est que le programmeur insiste sur le fait que chaque partie de son programme est correcte tandis que le résultat est défectueux. "-Vous n'avez pas besoin d'imprimer le tableau sur la console pour vérifier s'il est trié car la ligne ci-dessus est array.sort ()." "-Eh bien ... tu sais, ça ne marche pas. Il doit y avoir quelque chose qui ne va pas quelque part. Tu ne peux pas simplement défendre ton code à ce stade!"

— Gawi

2

Je pense qu'il est important de déboguer pour valider vos hypothèses sur l'ensemble de votre programme. Parfois, vous devez aller à la pêche pour trouver des indices. Cela doit être fait systématiquement. C’est parfaitement valable d’essayer quelque chose qui pourrait vous dire quelque chose de nouveau. Je le fais souvent.

— Gawi

37

Ne soyez pas intelligent être clair.
Utiliser avant de réutiliser.
Les noms comptent.
Une fonction fait 1 chose et le fait bien.
Petit vaut mieux que grand.

— KevBurnsJr
source

2

Pouvez-vous préciser "Utiliser avant de réutiliser". Je n'ai jamais entendu parler de cela auparavant.

— Tjaart

34

Les bases. Actuellement, les programmeurs apprennent des technologies et non des concepts. C'est faux.

— vitesse
source

Oui et non. Vous ressemblez à tous les profs que j'ai jamais eu à l'université ... qui n'ont jamais fait de logiciel dans leur vie. Le savoir sans compétences est inutile dans notre métier.

— Steven Evers le

4

+1, si vrai. Oui, c'est quelque chose que les types de tours d'ivoire aiment dire, mais cela ne le rend pas moins vrai pour le reste d'entre nous dans les tranchées.

— MAK

2

Des bases comme l'orthographe? Its wrongdevrait être it's wrong, par exemple.

— Konerak

2

Non, des notions de base, par exemple, ne s’inquiètent pas des fautes de frappe mais des problèmes de programmation.

— Clrod

5

Il est facile d'apprendre les étapes à suivre pour faire quelque chose et souvent difficile de savoir quand vous devez l'utiliser et, plus important encore, quand vous pouvez l'utiliser mais ne le devriez pas. Les manuels scolaires sont particulièrement mauvais pour montrer le comment mais pas le pourquoi (et pourquoi pas).

— HLGEM le

27

Chaque programmeur doit savoir qu'il met constamment des hypothèses dans le code, par exemple, "ce nombre sera positif et fini", "ce code sera capable de se connecter au serveur à tout moment en un clin d'œil".

Et il devrait savoir qu'il devrait se préparer à la rupture de ces hypothèses.

— LennyProgrammers
source

6

indiquer spécifiquement ceux avec assert()- partout. assert()vous aidera à documenter vos hypothèses et à vous sauver lorsque vous vous trompez.

— Dustin

@Dustin +1 Il est impossible que vous vous souveniez de toutes vos hypothèses - documentez-les par programme et vous serez informé du moment exact où elles se révéleront fausses.

— Skilldrick

1

... sauf si compilé avec NDEBUG.

19

Tous les programmeurs devraient être au courant des tests.

— Tom Duckering
source

6

Cela ne fonctionne que si vous l'avez testé.

— JD Frias

17

Apprendre des concepts . Vous pouvez Google la syntaxe.

— pramodc84
source

Bon en théorie, sauf que Google est terrible pour trouver une syntaxe spécifique : rechercher des termes tels que "référence d'objet" ou "ceci" étant donné un nombre de résultats équivalent, et rechercher des idiomes tels que "$?" ne donne aucun résultat.

— l0b0

16

Pensée critique et logique. vous ne pouvez rien faire de bien sans cela.

— Mladen Prajdic
source

14

Tests unitaires. C'est un excellent moyen de codifier vos hypothèses sur la manière dont le code doit être utilisé.

— btlog
source

14

Le minimum absolu que chaque développeur de logiciel a absolument, absolument besoin de savoir sur Unicode et les jeux de caractères (sans excuses!) .

— Carlos
source

13

C'est plus difficile que vous ne le pensez.

Bien qu'il soit facile (ish) de mettre en place quelque chose qui fonctionne normalement, gérer des entrées erronées, tous les cas de bords et de coins, les modes de défaillance possibles, etc. prend beaucoup de temps et sera probablement la partie la plus difficile du travail.

Ensuite, vous devez également donner à votre application une belle apparence.

— ChrisF
source

3

Je pense que ceci est la source du vieil adage «90% du travail prend 90% du temps. les 10%

— restants occupent

Je pense que beaucoup de gens ont tendance à toujours sous-estimer la complexité. "À quel point X peut-il être dur?" - Derniers mots célèbres: /

— Roman Starkov

@GSto Je ne veux pas travailler 180% du temps, 100% me convient parfaitement!

— Adam

13

Connaissance du domaine. La spécification n'est jamais à 100%; connaître le domaine avec lequel vous développez augmentera TOUJOURS la qualité du produit.

— Steven Evers
source

13

Big O notation et ses implications.

Quelques références utiles

— Slomojo
source

Je trouve que la notation Big O est l’un des principaux problèmes avec lesquels la plupart des informaticiens ont un problème (moi-même inclus)

— Richard

11

Des pointeurs, évidemment. :)

— Laurynas Biveinis
source

3

Les pointeurs ne sont vraiment nécessaires que dans un sous-ensemble de langues pour un petit sous-ensemble de tâches. Pour la plupart des tâches, vous pouvez (et devriez pouvoir) programmer comme si le concept de pointeur n'existait pas.

— Chinmay Kanchi

14

@Chinay Kanchi Non. Les pointeurs doivent être compris de tous.

— alternative le

5

Cela dépend vraiment de ce que vous entendez par pointeur. Si vous parlez de pointeurs de style C que vous pouvez manipuler (ce que j'ai supposé), je dirais qu'un programmeur Java / C # / Python n'a pas besoin de savoir quoi que ce soit à leur sujet. Si vous parlez de pointeur comme dans les "références" de Java, c’est-à-dire un pointeur qui ne peut pas être manipulé, alors, oui, une certaine connaissance de ces références est nécessaire, ne serait-ce que pour vous éviter de glisser.

— Chinmay Kanchi

@mathepic Vous serez bouleversé si vous appreniez combien d'étudiants en CS diplômés chaque année ne comprennent pas la première chose à propos des pointeurs. Si je n'avais pas fait tout mon possible pour effectuer des stages chaque été, on ne m'aurait même pas enseigné les indicateurs de C ou les références à Java ...

— Mike B

5

@Chinmay: Un programmeur Python / Java / C # qui ne comprend pas le concept de pointeurs est perdu. L = [[]] * 2; L[0].append(42) Différentes langues utilisent des noms différents, mais l' indirection est essentielle partout.

11

Code Complete 2 - de bout en bout

— Kyle Ballard
source

vous devriez vraiment le savoir avant d'accepter de l'argent pour programmer. Si vous trouvez quelque chose que vous ne saviez pas dedans, envisagez un changement de carrière ou une période intense d’études autogérées pour vous aider à tout comprendre. Et ensuite, excusez-vous auprès de vos collègues. Et cela ne couvre que les bases de la programmation.

— Tim Williscroft

11

Les données sont plus importantes que le code.

Si vos données sont intelligentes, le code peut être stupide.

Le code muet est facile à comprendre. Il en va de même pour les données intelligentes.

Presque chaque chagrin algorithmique que j'ai jamais eu est dû au fait que des données se trouvent au mauvais endroit ou ont été maltraitées. Si vos données ont un sens, inscrivez-le dans le système de types .

— Gonzales
source

2

Vous m'avez eu jusqu'à ce que vous disiez "système de type".

10

Quelle langue et quel environnement sont les plus appropriés pour le travail? Et ce n'est pas toujours ton préféré.

— Dan Diplo
source

10

Diviser et conquérir. C'est généralement le meilleur moyen de résoudre tout type de problème pratique, de la planification au débogage.

— Rick Minerich
source

8

Les compétences réelles se reflètent dans la capacité à exécuter correctement une conception simple, et non dans la capacité de réaliser une conception compliquée du tout.

Cette compétence provient d'une plus grande maîtrise des principes fondamentaux, et non de la maîtrise des arcanes. Un programmeur de haut calibre n'est pas défini par sa capacité à coder ce que d'autres ne peuvent pas (utiliser des fonctions de niveau supérieur, la programmation fonctionnelle avancée, que vous avez), mais plutôt par sa capacité à affiner le codage parfaitement banal. Choisir la décomposition appropriée des fonctionnalités entre les classes; construire en robustesse; utiliser des techniques de programmation défensives; et en utilisant des modèles et des noms qui conduisent à une plus grande auto-documentation, ce sont les ingrédients essentiels d'une programmation de haut calibre.

Écrire un bon code auquel vous, ou quelqu'un d'autre, pouvez revenir dans une semaine, un mois ou un an et comprendre comment utiliser, modifier, améliorer ou étendre ce code est crucial. Cela vous épargne du temps et des efforts mentaux. Il améliore la productivité en supprimant les obstacles sur lesquels vous auriez déjà trébuché (en interrompant peut-être votre pensée, en prenant des heures ou des jours d'efforts à d'autres travaux, etc.). Il est ainsi plus facile de se concentrer sur les problèmes difficiles. et parfois cela fait disparaître les problèmes difficiles.

En un mot: élégance. Chaque classe, chaque méthode, chaque condition, chaque bloc, chaque nom de variable: lutte pour l'élégance.

— Coin
source

8

Ne blâmez jamais l'utilisateur de ce qui pourrait être résolu avec une expérience utilisateur plus propre ou une meilleure documentation. Souvent, les programmeurs supposent automatiquement que l'utilisateur est un idiot qui ne peut rien faire de bien, lorsque le problème est une mauvaise expérience générale ou un manque de communication. Les programmes sont destinés à être utilisés, et traiter l’utilisateur avec mépris, c’est perdre le sens de la programmation.

— utilisateur8
source

6

Chaque programmeur doit savoir comment utiliser le débogueur, et savoir comment l'utiliser bien .

— Brian R. Bondy
source

5

Structures de données

— Maniero
source

5

Comment utiliser Google

— bruno077
source

4

L'évaluation des courts-circuits, bien que ce soit l'une des premières choses qu'ils apprennent sur les opérateurs booléens.

— Federico Klez Culloca
source

4

Comment évaluer avec précision le temps qu’il faudra à une fonctionnalité pour la mettre en oeuvre. Plus important encore, comment faire passer le message, vous ne faites pas de conneries quand vous soumettez cette estimation.

— blés
source

2

ou apprenez à bien vous servir de l'hôte et à bien faire passer le message que vous n'êtes pas un invité ...;)

— Billy Coover

4

Le style de codage compte:

questions d'indentation cohérente,
utilisation cohérente des espaces blancs (par exemple autour des opérateurs),
placement cohérent des sujets de {},
les identifiants bien choisis sont importants,
etc.

... et le bon design est important.

Idéalement, le programmeur apprend ces choses avant (ou pendant) sa première révision de code. Dans le pire des cas, le programmeur les apprend lorsque le chef lui dit de faire rapidement des modifications non triviales à un code horrible.

— Stephen C
source