Quel est votre avis sur la programmation le plus controversé?
Ceci est certainement subjectif, mais j'aimerais éviter que cela ne devienne argumentatif. Je pense que la question pourrait être intéressante si les gens la traitaient correctement.
L'idée de cette question est venue du fil de commentaire de ma réponse à la question "Quelles sont les cinq choses que vous détestez au sujet de votre langue préférée?" . J'ai soutenu que les classes en C # devraient être scellées par défaut - je ne vais pas exposer mon raisonnement dans la question, mais je pourrais écrire une explication plus complète pour répondre à cette question. J'ai été surpris par la chaleur de la discussion dans les commentaires (25 commentaires pour le moment).
Alors, quels sont les avis controversés que vous avez? Je préférerais éviter le genre de chose qui finit par être assez religieuse avec relativement peu de bases (par exemple, le placement d'accolades), mais des exemples pourraient inclure des choses telles que "les tests unitaires ne sont pas vraiment utiles" ou "les champs publics sont vraiment bons". L'important (pour moi en tout cas) est que vous avez des raisons derrière vos opinions.
Veuillez présenter votre opinion et votre raisonnement. J'encourage les gens à voter pour des opinions bien argumentées et intéressantes, que vous soyez d'accord ou non avec elles.
Macros, Préprocesseur instructions et Annotations sont diaboliques.
Une syntaxe et une langue par fichier s'il vous plaît!
// ne s'applique pas aux fichiers de création ou aux macros d'éditeur insérant du code réel.
Java est le COBOL de notre génération.
Tout le monde apprend à le coder. Il existe un code pour le faire fonctionner dans les grandes entreprises qui vont essayer de le garder pendant des décennies. Tout le monde en vient à le mépriser par rapport à tous les autres choix mais est obligé de l'utiliser quand même car il paie les factures.
Si vous avez déjà laissé quelqu'un de rentacoder.com aborder votre projet, celui-ci et votre entreprise n'ont aucune valeur.
Lors de la création de tests unitaires pour une couche d'accès aux données, les données doivent être extraites directement à partir de la base de données, et non à partir d'objets fictifs.
Considérer ce qui suit:
void IList<Customer> GetCustomers()
{
List<Customer> res = new List<Customer>();
DbCommand cmd = // initialize command
IDataReader r = cmd.ExecuteQuery();
while(r.read())
{
Customer c = ReadFiledsIntoCustomer(r);
res.Add(c);
}
return res;
}
Dans un test unitaire pour GetCustomers, l'appel à cmd.ExecuteQuery () doit-il accéder à la base de données ou son comportement doit-il être simulé?
Je pense que vous ne devriez pas vous moquer de l'appel réel à la base de données si les conditions suivantes sont vraies:
- Un serveur de test et le schéma existent.
- Le schéma est stable (ce qui signifie que vous ne vous attendez pas à des changements majeurs)
- Le DAL n'a pas de logique intelligente: les requêtes sont construites de manière triviale (config/processus stockés) et la logique de désirialisation est simple.
D'après mon expérience, le grand avantage de cette approche est que vous pouvez interagir tôt avec la DB, en expérimentant le "toucher", pas seulement le "look". Cela vous évite beaucoup de maux de tête par la suite et constitue le meilleur moyen de vous familiariser avec le schéma.
Beaucoup pourraient soutenir que dès que le flux d'exécution franchit les limites du processus, il se présente comme un test unitaire. Je conviens que cela présente des inconvénients, en particulier lorsque la base de données est indisponible et que vous ne pouvez pas exécuter UT.
Cependant, je pense que cela devrait être une chose valable à faire dans de nombreux cas.
Les programmeurs doivent éviter à tout prix de cacher une méthode par héritage.
D'après mon expérience, pratiquement tous les endroits où j'ai vu des méthodes héritées se cacher ont posé des problèmes. Lorsque la méthode est masquée, les objets se comportent différemment lors de l'accès via une référence de type de base par rapport à une référence de type dérivé - il s'agit généralement d'une mauvaise chose. Bien que de nombreux programmeurs n'en aient pas officiellement conscience, la plupart des gens s'attendent intuitivement à ce que les objets adhèrent au principe de substitution de Liskov . Lorsque les objets violent cette attente, bon nombre des hypothèses inhérentes aux systèmes orientés objet peuvent commencer à s'effilocher. Les cas les plus flagrants que j'ai vus sont ceux où la méthode cachée modifie l'état de l'instance d'objet. Dans ces cas, le comportement de l'objet peut changer de manière subtile, difficile à déboguer et à diagnostiquer.
Ok, il peut donc arriver que la dissimulation de méthodes soit utile et bénéfique, comme dans le cas de l’émulation de la covariance par type de retour de méthodes dans des langues qui ne la prennent pas en charge. Mais la plupart du temps, lorsque les développeurs utilisent une méthode pour la dissimuler, c'est par ignorance (ou par accident) ou comme moyen de résoudre un problème qui mérite probablement un meilleur traitement de la conception. En général, la dissimulation de méthodes (pour ne pas dire qu'il n'y en a pas d'autres) a été bénéfique lorsqu'une méthode sans effet secondaire qui renvoie des informations est masquée par une autre qui calcule quelque chose de plus applicable au contexte de l'appel.
Des langages comme C # ont un peu amélioré les choses en exigeant le mot-clé new sur les méthodes qui masquent une méthode de classe de base, ce qui permet au moins d'éviter l'utilisation involontaire du masquage de méthode. Mais je trouve que beaucoup de gens confondent encore le sens de new avec celui de override - d’autant plus que dans des scénarios simples, leur comportement peut sembler identique. Ce serait bien si des outils tels que FxCop avaient en fait des règles intégrées pour identifier les utilisations potentiellement mauvaises de la méthode cachée.
Soit dit en passant, la méthode cachée par héritage ne doit pas être confondue avec d’autres types de dissimulation - par exemple par imbrication - qui, à mon avis, est une construction valide et utile avec moins de problèmes potentiels.
Les fonctions anonymes sont nulles.
J'enseigne moi-même jQuery et, bien qu'il s'agisse d'une technologie élégante et extrêmement utile, la plupart des gens semblent la traiter comme une sorte de concurrence visant à maximiser l'utilisateur de fonctions anonymes.
La dénomination de fonction et de procédure (ainsi que la dénomination de variable) est la plus grande capacité d'expression que nous ayons en programmation. Transférer des fonctions en tant que données est une technique géniale, mais les rendre anonymes et donc non auto-documentées est une erreur. C'est une chance perdue pour exprimer le sens du code.
Les conceptions détaillées sont une perte de temps et si un ingénieur en a besoin pour faire un travail décent, il ne vaut pas la peine de les employer!
OK, quelques idées sont donc réunies ici:
1) la vieille idée de cascade le développement où vous supposément aviez effectué toute votre conception à l’avance, aboutissant à quelques diagrammes de classes extrêmement détaillés, diagrammes de séquence, etc. glorifiés, était une perte de temps totale. Comme je l'ai déjà dit à un collègue, j'en aurai fini avec le design une fois le code terminé. Ce qui, je pense, est en partie ce qu’agile est une reconnaissance de ce que le code est la conception, et que tout développeur décent est continuellement en train de refactoriser. Bien entendu, cela rend l’idée que vos diagrammes de classes sont périmés - ils le seront toujours.
2) la direction pense souvent qu’il est utile de prendre un ingénieur médiocre et de l’utiliser comme un "singe de code" - en d’autres termes, il n’est pas particulièrement doué, mais diable - ne pouvez-vous pas l’utiliser pour écrire du code. Et bien non! Si vous devez passer tellement de temps à rédiger des spécifications détaillées que vous spécifiez essentiellement le code, il sera alors plus rapide de l'écrire vous-même. Vous ne gagnez pas de temps. Si un développeur n'est pas assez intelligent pour utiliser son imagination et son jugement, il ne vaut pas la peine d'être utilisé. (Remarque, je ne parle pas d'ingénieurs débutants capables d'apprendre. Beaucoup d'ingénieurs expérimentés entrent dans cette catégorie.)
J'en ai deux:
Les modèles de conception sont parfois un moyen pour un mauvais programmeur d'écrire un mauvais code - "quand vous avez un marteau - tout le monde ressemble à un clou" mentalité. S'il y a quelque chose que je n'aime pas entendre, il y a deux développeurs qui créent des motifs: "Nous devrions utiliser la commande avec façade ...".
"l'optimisation prématurée" n'existe pas. Vous devez profiler et optimiser votre code avant d’arriver à ce point, lorsque cela devient trop pénible.
La taille, ça compte! Embellissez votre code pour le rendre plus gros.
Ne changez jamais ce qui n'est pas cassé.
Il n'y a qu'un seul modèle de conception: encapsulation
Par exemple:
- Méthode d'usine: vous avez créé des objets encapsulés
- Stratégie: vous avez encapsulé différents algorithmes modifiables
- Itérateur: vous avez encapsulé le moyen d'accéder séquentiellement aux éléments de la collection.
Stocker XML dans un CLOB dans une base de données relationnelle est souvent une horrible élimination. Non seulement cette performance est hideuse en termes de performances, mais elle incombe également à l’architecte de la base de données de gérer correctement la structure des données, au profit du programmeur d’application.
Le développement concerne 80% du design et 20% du codage
Je crois que les développeurs devraient consacrer 80% de leur temps à la conception au niveau de détail, à ce qu’ils vont construire, et à seulement 20% pour coder ce qu’ils ont conçu. Cela produira du code avec presque zéro bogue et économisera beaucoup sur le cycle test-fix-retest.
Entrer tôt dans le métal (ou IDE) est comme une optimisation prématurée, qui est connue pour être la racine de tous les maux. Une conception initiale réfléchie (je ne parle pas nécessairement d'un document de conception énorme, mais de simples dessins sur tableau blanc fonctionnera également) donnera de bien meilleurs résultats que le simple codage et correction.
Les projets de développement sont voués à l'échec si l'équipe de programmeurs n'a pas le pouvoir total de prendre toutes les décisions liées à la technologie utilisée.
Les mises à jour automatiques conduisent à un logiciel de qualité médiocre et moins sécurisé
L'idée
Un système pour maintenir les logiciels des utilisateurs à jour avec les dernières corrections de bugs et correctifs de sécurité.
La réalité
Les produits doivent être expédiés dans des délais fixes, souvent au détriment de l'assurance qualité. Le logiciel est alors publié avec de nombreux bugs et failles de sécurité afin de respecter l'échéance, sachant que la "mise à jour automatique" peut être utilisée pour résoudre ultérieurement tous les problèmes.
Maintenant, le logiciel qui m'a vraiment fait penser à cela est VS2K5. Au début, c’était génial, mais avec l’installation des mises à jour, le logiciel s’aggrave lentement. La plus grande offense était la perte de macros - j'avais longtemps créé un ensemble de macros VBA utiles pour automatiser une partie du code que j'écrivais - mais apparemment, il y avait un trou de sécurité et au lieu de le réparer, le système de macros a été désactivé. Bang utilise une fonction très utile: enregistrer des frappes au clavier et les rejouer plusieurs fois.
Maintenant, si j'étais vraiment paranoïaque, je pourrais voir les mises à jour automatiques comme un moyen d'inciter les gens à mettre à jour leurs logiciels en installant lentement un code qui casse le système plus souvent. À mesure que le système devient moins fiable, les utilisateurs sont tentés de payer pour la prochaine version avec la promesse d'une meilleure fiabilité, etc.
Skizz
Le logiciel de gestion des dépendances fait plus de mal que de bien
J'ai travaillé sur Java projets comprenant plus d'une centaine de bibliothèques différentes. Dans la plupart des cas, chaque bibliothèque a ses propres dépendances, et ces bibliothèques ont également leurs propres dépendances.
Un logiciel comme Maven ou Ivy est censé "gérer" ce problème en récupérant automatiquement la version correcte de chaque bibliothèque, puis en recherchant récursivement toutes ses dépendances.
Problème résolu, non?
Faux.
Le téléchargement de bibliothèques est la partie facile de la gestion des dépendances. La partie difficile consiste à créer un modèle mental du logiciel et de son interaction avec toutes ces bibliothèques.
Mon opinion impopulaire est la suivante:
Si vous ne pouvez pas expliquer verbalement et spontanément les interactions de base entre toutes les bibliothèques de votre projet, éliminez les dépendances jusqu'à ce que vous le puissiez.
Dans le même ordre d'idées, s'il vous faut plus de dix secondes pour répertorier toutes les bibliothèques (et leurs méthodes) invoquées directement ou indirectement à partir de l'une de vos fonctions, vous ne gérez pas bien les dépendances.
Vous devriez pouvoir répondre facilement à la question "Quelles parties de mon application dépendent réellement de la bibliothèque XYZ?"
La série actuelle d’outils de gestion des dépendances fait plus de mal que de bien, car elle facilite la création de graphiques de dépendance extrêmement complexes et ne fournit pratiquement aucune fonctionnalité permettant de réduire les dépendances ou d’identifier les problèmes.
J'ai vu des développeurs inclure des bibliothèques d'une valeur de 10 ou 20 Mo, introduisant des milliers de classes dépendantes dans le projet, simplement pour éliminer quelques dizaines de lignes de code personnalisé simple.
Utiliser des bibliothèques et des frameworks peut être bon. Mais il y a toujours un coût, et les outils qui masquent ce coût sont intrinsèquement problématiques.
De plus, il est parfois (note: certainement pas toujours) préférable de réinventer la roue en écrivant quelques petites classes qui implémentent ce dont vous avez besoin exactement plutôt que d'introduire une dépendance à une grande bibliothèque polyvalente.
Pour être vraiment controversé:
Vous ne savez rien!
ou en d'autres termes:
Je sais que je ne sais rien.
(Cela pourrait être paraphrasé dans beaucoup de genres mais je pense que vous l'obtenez.)
Quand on commence avec des ordinateurs/en développement, à mon humble avis, il y a trois étapes que tout le monde doit parcourir:
Le débutant: ne sait rien (c'est un fait)
L'intermédiaire: pense qu'il sait quelque chose/beaucoup (/ tous) (c'est la vanité)
Le professionnel: sait qu'il ne sait rien (car en tant que programmeur, la plupart du temps, vous devez travailler sur des choses que vous n'avez jamais faites auparavant). Ce n'est pas une mauvaise chose: j'adore me familiariser avec de nouvelles choses tout le temps.
Je pense qu'en tant que programmeur, vous devez savoir apprendre - ou mieux: apprendre à apprendre (car souvenez-vous: vous ne savez rien!;)).
Les modèles de conception sont incorrects.
En fait, les modèles de conception ne sont pas .
Vous pouvez écrire un mauvais code et l'enterrer sous une pile de motifs. Utilisez des singletons en tant que variables globales et des états en tant que goto. Peu importe.
Un modèle de conception est une solution standard pour un problème particulier, mais vous devez d'abord comprendre le problème. Si vous ne le faites pas, les modèles de conception deviennent une partie du problème pour le prochain développeur.
Il y a quelques (très peu) utilisations légitimes de goto (notamment en C, en remplacement de la gestion des exceptions).
80% des bugs sont introduits au stade de la conception.
Les 80% restants sont introduits au stade du codage.
(Cette opinion a été inspirée par la réponse de Dima Malenko. "Le développement concerne 80% du design et 20% du codage", oui. "Cela produira du code avec un bogue proche de zéro", non.)
ne classe par fichier
On s'en fout? Je préfère de loin les programmes entiers contenus dans un fichier plutôt qu'un million de fichiers différents.
Tcl/Tk est le meilleur combo langage/toolkit jamais créé
Il manque peut-être des widgets spécifiques et est moins beau que les nouveaux venus, mais son modèle est élégant et si facile à utiliser que l'on peut construire des interfaces graphiques fonctionnant plus rapidement en tapant les commandes de manière interactive plutôt qu'en utilisant un constructeur d'interface visuelle. Son pouvoir d’expression est imbattable: d’autres solutions (Gtk, Java, .NET, MFC, etc.) nécessitent généralement de 10 à 100 LOC pour obtenir le même résultat qu’un one-liner Tcl/Tk. Le tout sans même sacrifier la lisibilité ou la stabilité.
pack [label .l -text "Hello world!"] [button .b -text "Quit" -command exit]
Ce logiciel peut être sans bug si vous avez les bons outils et prenez le temps de l'écrire correctement.
Opinion: Ne pas avoir de définitions de fonction et les types de retour peuvent conduire à un code flexible et lisible.
Cette opinion s’applique probablement plus aux langages interprétés que compilés. Exiger un type de retour et une liste d'arguments de fonctions est idéal pour des choses comme intellisense qui permet de documenter automatiquement votre code, mais ce sont aussi des restrictions.
Maintenant, ne vous méprenez pas, je ne dis pas que les types de retour, ou les listes d'arguments, sont à jeter. Ils ont leur place. Et 90% du temps, ils sont plus un avantage qu'un obstacle.
Il y a des moments et des endroits où cela est utile.
Je préférerais être vraiment compétent/expérimenté dans une technologie plus ancienne qui me permet de résoudre efficacement les problèmes du monde réel, par opposition aux nouvelles technologies "à la mode" qui traversent encore le stade de l'adolescence.
Si vous n'avez pas lu de page de manuel, vous n'êtes pas un vrai programmeur.
La réutilisation de logiciel est le moyen le plus important d'optimiser le développement de logiciel
D'une certaine manière, la réutilisation de logiciels semble être à la mode depuis un certain temps, mais a perdu de son charme, lorsque de nombreuses entreprises ont découvert que le simple fait d'écrire des présentations PowerPoint avec des slogans de réutilisation n'aide en réalité pas. Ils ont estimé que la réutilisation de logiciels n'était tout simplement pas "assez bonne" et ne pouvait pas être à la hauteur de leurs rêves. Il semble donc que ce n’est plus à la mode: il a été remplacé par de nombreux nouveaux venus dans le domaine de la gestion de projets (Agile par exemple).
Le fait est que tout bon développeur effectue à lui seul une sorte de réutilisation de logiciel. Je dirais que Tout développeur qui ne fait pas de réutilisation de logiciel est un mauvais développeur!
J'ai moi-même constaté à quel point la réutilisation de logiciels peut générer des performances et une stabilité en développement. Mais bien sûr, un ensemble de PowerPoints et d’aveux sans conviction de la direction ne suffit pas pour exploiter tout son potentiel dans une entreprise.
J'ai lié un très vieil article de mon travail sur la réutilisation de logiciels (voir le titre). Il a été à l'origine écrit en allemand et traduit par la suite - alors, excusez-moi, s'il ne l'est pas.
Il est correct d'utiliser des noms de variables courts
Mais pas pour les index dans les boucles imbriquées.
Développer sur .NET n'est pas de la programmation. C'est simplement assembler le code des autres.
Venant d'un contexte de codage dans lequel vous deviez connaître le matériel, et où il s'agit toujours d'une exigence vitale dans mon secteur, je considère les langages de haut niveau comme un simple assemblage du travail de quelqu'un d'autre. Rien de fondamentalement faux avec cela, mais s'agit-il de "programmation"?
MS a fait tout son possible pour accomplir ce travail difficile et présenter aux développeurs une syntaxe d'instructions symboliques. Il semble que je connaisse maintenant de plus en plus de développeurs qui semblent contraints par l’existence ou non d’une classe pour effectuer un travail.
Mon opinion vient de la notion que pour être programmeur, vous devriez pouvoir programmer au niveau le plus bas que votre plate-forme permet. Donc, si vous programmez .NET, vous devez être en mesure de vous dissimuler et de trouver la solution, plutôt que de vous fier à quelqu'un d'autre qui crée un cours pour vous. C'est simplement paresseux et ne constitue pas un développement dans mon livre.
2 espace de retrait.
Pas de discussion. C'est juste comme ça ;-)
N'implémentez jamais rien en tant que singleton.
Vous pouvez décider de ne pas créer plus d'une instance, mais assurez-vous toujours que votre implémentation peut en gérer plus.
Je n'ai pas encore trouvé de scénario où l'utilisation d'un singleton est en fait la bonne chose à faire.
J'ai eu des discussions très animées à ce sujet au cours des dernières années, mais au final, j'avais toujours raison.
Vous ne pouvez pas écrire une application Web sans un débogueur distant
Les applications Web associent généralement des interactions entre plusieurs langues côté client et serveur, requièrent une interaction de l'utilisateur et incluent souvent du code tiers pouvant aller de la simple implémentation d'API à une infrastructure byzantine.
J'ai perdu le compte du nombre de fois où un autre développeur est assis avec moi alors que j'exploite ce qui se passe réellement dans une application Web complexe avec un débogueur distant décent pour les voir sidérés et étonnés de l'existence de tels outils. . Souvent, ils ne prennent toujours pas la peine d'installer et de configurer ce type d'outils même après les avoir vus en action.
Vous ne pouvez pas déboguer une application Web non triviale avec des instructions d'impression. Dix fois si vous n'avez pas corrigé tout le code de votre application.
Si votre débogueur peut parcourir toutes les langues utilisées et vous montrer les transactions http en cours, tant mieux.
Vous ne pouvez pas développer d'applications Web sans Firebug
Dans le même ordre d'idées, une fois que vous avez utilisé Firebug (ou à peu près équivalent), vous regardez ceux qui essaient de développer des applications Web mêlant pitié et horreur. En particulier avec Firebug affichant les styles calculés, si vous vous rappelez de NE PAS l'utiliser et passer des heures à modifier aléatoirement divers bits de CSS et à ajouter "! Important" dans trop d'endroits pour être drôle, vous ne serez jamais retour .
switch-case n'est pas une programmation orientée objet
Je vois souvent beaucoup de casse-tête ou de très gros modèles if-else. Ceci est simplement un signe pour ne pas mettre l'état où il appartient et ne pas utiliser la construction switch-case réelle et efficace qui est déjà présente: method lookup/vtable
Croyez-le ou non, je pense que dans un langage OO, la plupart du code (logique métier) qui opère sur les données d'une classe doit être dans la classe elle-même est une hérésie sur mon équipe.
Les abstractions de haut niveau utiles et propres sont significativement plus importantes que la performance
un exemple:
Trop souvent, je vois des collègues passer des heures à écrire sur des Sprocs compliqués ou sur des requêtes LINQ volumineuses qui renvoient des types anonymes non intuitifs pour des raisons de "performances".
Ils pourraient atteindre presque les mêmes performances mais avec un code considérablement plus propre et intuitif.
... que la "clarification des idées" ne soit pas la responsabilité exclusive du développeur ... et oui xkcd m'a fait utiliser cette phrase en particulier ...
Trop souvent, nous recevons des projets spécifiés dans un "code" spécifique à psuedo-meta-sorta-kinda si vous voulez l'appeler ainsi. Il y a souvent des chefs de produit qui établissent les exigences initiales d'un projet et effectuent près de 0% de la validation logique de base.
Je ne dis pas que l'approche technique ne devrait pas être élaborée par l'architecte, ni que l'implémentation spécifique ne devrait pas incomber au développeur, mais plutôt que le responsable du produit devrait être tenu de veiller à ce que leurs exigences soient respectées. sont logiquement réalisables.
Personnellement, j'ai été impliqué dans trop de projets "simples" qui rencontrent un léger changement de portée ici et là, puis un "petit" changement ou une addition de fonctionnalités qui contredit les exigences précédentes - de manière implicite ou explicite. Dans ces cas, il est trop facile pour la personne qui demande le changement limite - impossible de se mettre en colère que les développeurs ne puissent pas réaliser leur rêve.
Ce qui me semble amusant sur cette question, c'est que je viens de lire la première page de réponses et que, jusqu'à présent, je n'ai trouvé aucun avis controversé.
Peut-être cela en dit-il plus sur la façon dont stackoverflow génère un consensus qu'autre chose. J'aurais peut-être dû commencer par le bas. :-)
Les meilleures pratiques ne sont pas.
La programmation fonctionnelle n'est PAS plus intuitive ou plus facile à apprendre que la programmation impérative.
Il y a beaucoup de bonnes choses à propos de la programmation fonctionnelle, mais j'entends souvent les programmeurs fonctionnels dire qu'il est plus facile de comprendre la programmation fonctionnelle que la programmation impérative pour les personnes sans expérience en programmation. D'après ce que j'ai vu, c'est l'inverse qui se passe, les gens trouvent qu'il est difficile de résoudre des problèmes insignifiants car ils ne savent pas comment gérer et réutiliser leurs résultats temporaires lorsque vous vous retrouvez dans un monde sans État.
Je dirais que mon opinion la plus controversée sur la programmation est que je crois honnêtement que vous ne devriez pas trop vous préoccuper du code jetable et de la réécriture du code. Trop de fois, les gens pensent que si vous écrivez quelque chose, cela signifie que vous avez fait quelque chose de mal. Mais la façon dont mon cerveau fonctionne est de faire quelque chose de très simple et de mettre à jour le code lentement, tout en veillant à ce que le code et le test continuent de fonctionner ensemble. Il se peut qu’il finisse par créer des classes, des méthodes, des paramètres supplémentaires, etc. Je sais parfaitement que cela disparaîtra dans quelques heures. Mais je le fais parce que je veux faire seulement de petits pas vers mon objectif. En fin de compte, je ne pense pas que je passe plus de temps à utiliser cette technique que les programmeurs qui fixent l'écran pour essayer de trouver la meilleure conception avant de rédiger une ligne de code.
L’avantage que j’obtiens, c’est que je n’ai pas à faire constamment face à des logiciels qui ne fonctionnent plus, c’est parce que j’arrive à le casser d’une manière ou d’une autre et j’essaie de déterminer ce qui a cessé de fonctionner et pourquoi.
MS Access * est un outil de développement réel pouvant être utilisé sans honte par les programmeurs professionnels
Ce n’est pas parce qu’une plate-forme particulière attire des hackers et des secrétaires qui pensent être des programmeurs que la plate-forme elle-même ne doit pas être négligée. Chaque plate-forme a ses avantages et ses inconvénients.
Les programmeurs qui déplorent certaines plateformes ou certains outils ou les considèrent comme des "jouets" ont plus de chances d’être beaucoup moins au courant de leur métier que leur ego ne les a convaincus. C'est pour moi un signe excessif de confiance d'entendre un programmeur critiquer un environnement qu'il n'a pas suffisamment utilisé personnellement pour bien le connaître.
* Insérez ici n'importe quel outil maligne (VB, PHP, etc.).
Pour être un bon programmeur, il faut vraiment travailler dans plusieurs aspects du domaine: développement d'applications, travail des systèmes (noyau), conception d'interface utilisateur, base de données, etc. Il existe certaines approches communes à tous et certaines approches spécifiques à un aspect du travail. Vous devez apprendre à programmer Java comme un codeur Java, et non comme un codeur C++ et inversement. La conception de l'interface utilisateur est très difficile et utilise une partie de votre cerveau différente de celle du codage, mais implémenter cette interface dans le code est une autre compétence également. Ce n’est pas seulement qu’il n’ya pas une approche "unique" au codage, mais qu’il n’ya pas un seul type de codage.
Code as Design: Trois essais de Jack W. Reeves
Le code source de tout logiciel est son document de conception le plus précis. Tout le reste (spécifications, documents et parfois commentaires) est incorrect, obsolète ou trompeur.
Garanti de te faire virer un peu partout.
Simplicité vs optimalité
Je crois qu'il est très difficile d'écrire un code à la fois simple et optimal.
Opinion: La durée dans le domaine du développement ne signifie pas toujours la même chose que l'expérience.
De nombreux métiers se réfèrent aux "années d'expérience" dans une langue. Oui, 5 ans de C # peuvent avoir un sens puisque vous pouvez apprendre de nouveaux trucs et ce qui ne l’est pas. Toutefois, si vous êtes au service de la société et que vous conservez la même base de code pendant plusieurs années, j’ai l’impression que vous ne gagnez pas suffisamment d’exposition à différentes situations en tant que personne qui travaille pour différentes situations et pour différents besoins de clients.
Une fois, j'ai interviewé une personne fière de ses 10 années d'expérience en programmation et qui travaillait avec VB5, 6 et VB.Net ... le tout dans la même entreprise pendant cette période. Après un examen plus approfondi, j'ai découvert que s'il travaillait avec toutes ces versions de VB, il ne faisait que mettre à niveau et maintenir constamment son application VB5 d'origine. Jamais modifié l'architecture et laissez les assistants de mise à niveau faire leur travail. J'ai interviewé des personnes qui n'ont que 2 ans dans le domaine mais qui ont travaillé sur plusieurs projets qui ont plus "d'expérience" que lui.
La programmation est si facile qu'un enfant de cinq ans peut le faire.
La programmation en soi n'est pas difficile, c'est du bon sens. Vous dites simplement à un ordinateur quoi faire. Vous n'êtes pas un génie, veuillez vous en remettre.
Les tuples (non nommés) sont diaboliques
- Si vous utilisez des tuples en tant que conteneur de plusieurs objets ayant une signification unique, utilisez plutôt une classe.
- Si vous les utilisez pour contenir plusieurs objets devant être accessibles par index, utilisez une liste.
Si vous les utilisez pour renvoyer plusieurs valeurs d'une méthode, utilisez plutôt les paramètres Out (cela nécessite que votre langue prenne en charge le passage par référence).
Si cela fait partie d'une stratégie d'obfuscation de code, continuez à les utiliser!
Je vois des gens utiliser des n-uplets simplement parce qu'ils sont trop paresseux pour se donner la peine de donner des noms à leurs objets. Les utilisateurs de l'API sont ensuite forcés d'accéder aux éléments du tuple en se basant sur un index sans signification au lieu d'un nom utile.
Ne vous décidez jamais sur un problème avant d’en avoir examiné en détail le problème. Aucune norme de programmation ne justifie JAMAIS de mal aborder un problème. Si la norme demande qu'une classe soit écrite, mais après mûre réflexion, vous estimez qu'une méthode statique est plus appropriée, utilisez toujours la méthode statique. Votre propre discrétion est toujours meilleure que même le meilleur en matière de réflexion prospective de celui qui a écrit la norme. Les normes sont excellentes si vous travaillez en équipe, mais les règles doivent être enfreintes (de bon goût, bien sûr).
Je pense que c'est bien d'utiliser des instructions goto, si vous les utilisez de façon saine (et un langage de programmation sain). Ils peuvent souvent rendre votre code beaucoup plus facile à lire et ne vous obligent pas à utiliser une logique tordue juste pour faire une chose simple.
Je n'ai pas encore testé la controverse, mais il pourrait y avoir un potentiel:
La meilleure ligne de code est celle que vous n'avez jamais écrite.
Xah Lee : a en fait des points de vue assez remarquables et légitimes si vous pouvez filtrer toutes les invectives et évaluer rationnellement les déclarations sans s'accorder (ou être en désaccord) sur la seule base de la personnalité derrière les déclarations. Il a fait écho à nombre de ses points de vue "controversés", ainsi qu'à d'autres "trolls" notoires qui critiquent régulièrement les langages ou les outils que j'utilise (d).
[Générateurs de documentation] ( http: //en.wikipedia.or /wiki/Comparison_of_documentation_generators): ... le genre où le créateur a inventé des créations sur mesure spécialement conçues pour la documentation de sources, roll-your syntaxe interne (y compris, mais sans s'y limiter, JavaDoc) sont totalement superflues et constituent une perte de temps, car:
- 1) Ils sont sous-utilisés par les personnes qui devraient les utiliser le plus souvent. et
- 2) Toutes ces mini-langues de documentation toutes pourraient facilement être remplacées par YAML
N'utilisez pas de mots-clés pour les types de base si le type réel est exposé dans la langue. En C #, cela ferait référence à bool (Boolean), int (Int32), float (Single), long (Int64). 'int', 'bool', etc. ne sont pas des parties réelles du langage, mais plutôt des 'raccourcis' ou des 'alias' pour le type actuel. N'utilisez pas quelque chose qui n'existe pas! Et à mon avis, Int16, Int32, Int64, Boolean, etc. font beaucoup plus de sens que "court", "long", "int".
Apparemment, il est controversé que l'IDE devrait vérifier pour voir s'ils peuvent relier le code qu'ils créent avant de perdre du temps à compiler
Mais je suis d’avis que je ne devrais pas compiler un zillion de lignes de code pour me rendre compte que Windows a un verrou sur le fichier que je suis en train de créer car un autre programmeur a un problème de thread étrange qui l’oblige à retarder le déchargement des DLL. pendant 3 minutes après qu'ils ne sont pas censés être utilisés.
Comme beaucoup d’autres ici, j’essaie d’adhérer à des principes tels que DRY et de ne pas être un compilateur humain.
Une autre stratégie que je veux pousser est "dites, ne demandez pas". Au lieu d'encombrer tous les objets avec des getters/setters, je voudrais plutôt leur dire de faire des choses.
Cela semble aller directement à l'encontre des bonnes pratiques d'entreprise avec des objets d'entité stupides et une couche de service plus épaisse (qui demande beaucoup de temps). Hmmm, des pensées?
Les gens se plaignent de la suppression de 'goto' de la langue. Je pense que toute sorte de saut conditionnel est fortement surestimé et que "si", "tout", "commutateur" et tout usage "pour" boucle sont fortement surestimés et doivent être utilisés avec une extrême prudence.
Chaque fois que vous effectuez une comparaison et un saut conditionnel, une petite complexité est ajoutée et cette complexité s’ajoute rapidement une fois que la pile d’appels a atteint une centaine d’éléments.
Mon premier choix est d’éviter le conditionnel, mais si cela n’est pas pratique, ma préférence suivante est de conserver la complexité conditionnelle dans les constructeurs ou les méthodes d’usine.
Clairement, cela n’est pas pratique pour de nombreux projets et algorithmes (comme les boucles de flux de contrôle), mais c’est quelque chose que j’aime bien pousser.
-Meule
Python fait tout ce que font les autres langages de programmation en deux fois moins de temps que prévu ... et Google aussi !!! Départ nladen Swallow si vous n'êtes pas d'accord.
Attendez, c'est un fait. Est-ce toujours considéré comme une réponse à cette question?
C++ est le futur langage tueur ...
... de langages dynamiques.
personne ne le possède, possède un ensemble croissant de fonctionnalités telles que la programmation (méta) à la compilation ou l'inférence de type, les rappels sans surcharge des appels de fonction, n'applique pas une approche unique (multi-paradigme). POSIX et ECMAScript expressions régulières . valeurs de retour multiples . vous pouvez avoir arguments nommés . etc.
les choses avancent très lentement dans la programmation. Il a fallu 10 ans à JavaScript pour prendre son envol (principalement à cause des performances), et la plupart des personnes qui le programment ne l’ont toujours pas (cours en JS? C’mon!). Je dirais que C++ va vraiment commencer à briller dans 15 à 20 ans. cela me semble être le temps qu'il faut au C++ (le langage, ainsi que les constructeurs de compilateurs) et à la masse critique de programmeurs qui écrivent aujourd'hui dans des langages dynamiques pour converger.
Le C++ doit devenir plus convivial pour les programmeurs (erreurs de compilation générées à partir de modèles ou de temps de compilation en présence de ceux-ci), et les programmeurs doivent se rendre compte que le typage statique est une aubaine (il est déjà en cours, voir autre réponse ici qui affirme le code écrit dans un langage typé dynamiquement s’écrit comme si le langage était typé statiquement).
L’AQ peut être bien faite, à long terme, sans explorer toutes les formes de test
Beaucoup d'endroits semblent avoir une "approche", comment "on le fait". Cela semble exclure implicitement les autres approches.
Il s’agit d’un grave problème à long terme, car la principale fonction de l’assurance qualité consiste à archiver les bogues et à les corriger.
Vous ne pouvez pas le faire si vous ne trouvez pas le plus de bogues possible. Lorsque vous excluez des méthodologies, par exemple, en étant trop dépendant de la boîte noire, vous commencez à ignorer des classes entières d'erreurs de codage découvrables. Cela signifie implicitement que vous faites en sorte que des classes entières d’erreurs de codage ne puissent plus être corrigées, sauf lorsque quelqu'un d’autre trébuche dessus.
Le problème sous-jacent semble souvent être le management + staff. Les gestionnaires confrontés à ce problème semblent avoir une vision étroite de l’informatique et/ou de la proposition de valeur de leur équipe. Ils ont tendance à créer des équipes qui reflètent leur approche et une liste blanche de méthodes de test.
Je ne dis pas que vous pouvez ou devez tout faire tout le temps. Voyons les choses en face, certaines méthodes de test vont simplement être une perte de temps pour un produit donné. Et certaines méthodologies sont plus utiles à certains niveaux de maturité du produit. Mais ce qui manque, à mon avis, c’est la capacité des organisations de test à se mettre au défi d’apprendre de nouvelles choses et de les appliquer à leur performance globale.
Voici une conversation hypothétique qui résumerait:
Moi: Vous avez testé ce script de démarrage pendant 1 ans, et vous avez réussi à apprendre RIEN sur les scripts Shell et leur fonctionnement?!
Testeur: oui.
Moi: Autorisations?
Testeur: l'installateur fait ça
Moi: Plate-forme, dépendances spécifiques à la version?
Testeur: Nous déposons des bugs pour cela
Moi: Erreur de traitement?
Testeur: quand des erreurs arrivent au support client nous envoie des informations.
Moi: d'accord ... (commence à penser à écrire un post dans stackoverflow ...)
Il y a une différence entre un programmeur et un développeur. Un exemple: un programmeur écrit la logique de pagination, un développeur intègre la pagination sur une page.
"XML et HTML sont le" langage d'assemblage "du Web. Pourquoi le pirater encore?
Il semble assez évident que très peu de développeurs de nos jours apprennent/codent en langage Assembly car ils sont primitifs et vous éloignent du problème à résoudre à un niveau élevé. Nous avons donc inventé des langages de haut niveau pour encapsuler ces entités de niveau afin d’améliorer notre productivité grâce aux éléments de langage auxquels nous pouvons nous associer davantage au plus haut niveau. Tout comme nous pouvons faire plus avec un ordinateur que sa carte mère ou son processeur.
Avec le Web, il me semble que les développeurs continuent à lire/écrire et à pirater HTML, CSS, XMl, schémas, etc.
Je les vois comme l'équivalent du "langage d'assemblage" du Web ou de ses substrats. Faut-il en finir? Bien sûr, nous devons le pirater parfois lorsque les choses tournent mal. Mais c'est sûrement une exception. J'affirme que nous remplaçons le langage d'assemblage de niveau inférieur au niveau machine par son équivalent au niveau Web.
Les exceptions considérées comme nuisibles.
Il n'y a que 2 types de personnes qui utilisent le C (/ C++): ceux qui ne connaissent aucune autre langue et ceux qui sont trop paresseux pour en apprendre une nouvelle.
Lorsque de nombreuses nouvelles technologies apparaissent sur la scène, j'en apprends juste assez à leur sujet pour décider si j'en ai besoin maintenant.
Sinon, je les mets de côté jusqu'à ce que les "adoptants précoces" aient éliminé les contours brusques, puis revérifie tous les quelques mois/années.
La "Programmation des perles" de Jon Bentley n'est plus un tome utile.
Je pense que nous devrions nous éloigner de 'C'. C'est trop vieux! Mais, le vieux chien aboie toujours plus fort !!
Que (du moins lors de la conception initiale), chaque table de base de données (enfin, presque toutes) devrait être clairement définie pour contenir une abstraction clairement compréhensible d'entité commerciale ou de domaine au niveau du système, et que vous l'utilisiez ou non comme une clé primaire et en tant que clés étrangères dans d'autres tables dépendantes, certains attributs de colonne (attribut) ou sous-ensemble de la table doivent être clairement définis pour représenter une clé unique pour cette table (entité/abstraction). C'est le seul moyen de garantir que la structure globale de la table représente une représentation cohérente de la structure complète des données du système, sans chevauchement ni aplatissement mal interprété. Je suis un partisan convaincu de l'utilisation de clés de substitution non significatives pour Pks et Fks et de la fonctionnalité de jointure (performances, facilité d'utilisation, etc.), mais je crois que la tendance dans cette direction a trop éloigné la communauté de la base de données. les principes de Cobb originaux, et nous avons perdu une grande partie des avantages (de la cohérence de la base de données) fournis par les clés naturelles.
Alors pourquoi ne pas utiliser les deux?
Les gestionnaires savent tout
D'après mon expérience, les gestionnaires n'y arrivaient pas en connaissant le code en général. Peu importe ce que vous leur dites, c'est trop long, pas bien ou trop cher.
Et une autre qui fait suite à la première:
Il n'y a jamais de temps pour le faire correctement mais il y a toujours du temps pour le refaire
Un bon ami ingénieur a déclaré un jour que, décrié par la colère, il décrivait une situation dans laquelle la direction réduisait de moitié ses estimations, obtenait une version à moitié démontée de lui puis lui donnait deux fois plus de temps pour la retravailler car elle échouait. C'est une chose assez courante dans le monde des logiciels commerciaux.
Et celui qui me venait à l’esprit aujourd’hui en essayant de configurer un routeur avec seulement une interface Web:
les interfaces Web sont pour les ventouses
La CLI de la version précédente du micrologiciel était très agréable. Cette version possède une interface Web, qui tente de dissimuler toute la complexité de la mise en réseau aux droïdes informatiques sans rien comprendre, et ne parvient même pas à obtenir des VLAN corrects.
Les ingénieurs en logiciel ne devraient pas travailler avec des informaticiens
Leurs différences: les SE se soucient de la réutilisation du code, alors que les CS se contentent de se soucier de la performance, alors que les CS veulent juste que les choses soient faites maintenant que les SE se soucient de la structure entière, tandis que les CS ne se laissent pas ...
Je ne crois pas que toute question liée à l'optimisation devrait être submergée par un slogan de "L'optimisation prématurée est la racine de tous les maux", car le code optimisé pour l'obscurcissement est ce qui rend le codage amusant.
Les tableaux associatifs/les cartes de hachage/les tables de hachage (+ quel que soit son nom appelé dans votre langue préférée) sont la meilleure chose depuis le pain en tranches!
Bien sûr, ils fournissent une recherche rapide de la clé à la valeur. Mais ils facilitent également la construction de données structurées à la volée. Dans les langages de script, il s’agit souvent du seul (ou du moins du plus utilisé) moyen de représenter des données structurées.
IMHO ils étaient un facteur très important pour le succès de nombreux langages de script.
Et même en C++, std :: map et std :: tr1 :: unordered_map m'ont aidé à écrire du code plus rapidement.
Le codage en dur est bon!
Vraiment, plus efficace et beaucoup plus facile à maintenir dans de nombreux cas!
Le nombre de fois que j'ai vu des constantes mettre dans des fichiers de paramètres vraiment combien de fois allez-vous changer le point de congélation de l'eau ou la vitesse de la lumière?
Pour les programmes C, codez simplement ces types de valeurs dans un fichier d’en-tête, pour Java dans une classe statique, etc.
Lorsque ces paramètres ont un effet considérable sur le comportement de vos programmes et que vous souhaitez réellement effectuer un test de régression à chaque changement, cela semble plus naturel avec les valeurs codées en dur. Quand les choses sont stockées dans des fichiers de paramètres/propriétés, la tentation est de penser "ce n’est pas un problème de programme, je n’ai donc pas besoin de le tester".
L’autre avantage est d’empêcher les gens de s’immiscer dans les valeurs essentielles des fichiers de paramètres/propriétés, car il n’en existe aucune!
"else" est nocif.
Avoir un processus qui implique l'approbation du code avant qu'il ne soit fusionné sur la ligne principale est une idée terrible. Cela engendre l’insécurité et la paresse chez les développeurs qui, s’ils savaient qu’ils pourraient bousiller des dizaines de personnes, feraient très attention aux changements qu’ils apportent, se laisser bercer et ne plus avoir à penser à tous les clients possibles du code peut affecter. La personne qui consulte le code a moins tendance à y penser autant que la personne qui l’a écrit. Cela peut donc conduire à l’enregistrement de code de qualité plus médiocre ... bien que, oui, il respectera probablement toutes les directives de style et soyez bien commenté :)
Agile est nul.
Que la loi de Demeter , considérée dans un contexte d'agrégation et de composition, est un anti-modèle.
Je suis d'avis qu'il y a trop de personnes qui prennent des décisions en matière de programmation sans se soucier de la mise en œuvre.
Il suffit de 3 à 5 langues pour tout faire. C est une définitive. Peut-être l'Assemblée mais vous devriez le savoir et pouvoir l'utiliser. Peut-être que javascript et/ou Java si vous codez pour le Web. Un langage Shell comme bash et un HLL, comme LISP, pourraient être utiles. Tout le reste est une distraction.
Ni Visual Basic ni C # ne l'emportent sur l'autre. Ils sont à peu près les mêmes, sauf la syntaxe et le formatage.
Voici la mienne:
"Vous n'avez pas besoin de la syntaxe (textuelle) pour exprimer les objets et leur comportement."
Je souscris aux idées de Jonathan Edwards et de son projet Subtext - http://alarmingdevelopment.org/
Bientôt nous allons programmer dans n monde sans bases de données.
AOP et injection de dépendance sont le GOTO du 21ème siècle.
Le logiciel de construction est une activité sociale, pas une activité technique.
Joel a un blog.
Je pense que Java devrait avoir pris en charge des fonctionnalités spécifiques au système via des wrappers de bibliothèques natives minces.
En d'autres termes, je pense que la détermination de Sun d'exiger que Java ne prenne en charge que les fonctionnalités portables soit une grave erreur du point de vue de presque tout le monde.
Un an et demi plus tard, SWT arriva et résolut le problème de base de l'écriture d'une interface utilisateur de widget native portable, mais à ce moment-là, Microsoft était obligé d'insérer Java en C # et beaucoup de C++ avaient été écrits. été fait en Java civilisé. Maintenant, le monde fonctionne avec un mélange de C #, VB, Java, C++, Ruby, Python et Perl. Tous les programmes Java ont toujours un aspect et un comportement étranges, à l’exception des programmes SWT.
Si Java était sorti avec des enveloppes minces autour des bibliothèques natives, les gens auraient pu écrire l'équivalent SWT entièrement en Java, et nous aurions pu, apparemment, rendre portable apparemment. applications natives en Java. Je suis totalement pour les applications portables, mais il aurait été préférable que cette portabilité soit réalisée sur un marché ouvert de bibliothèques d'interfaces middleware (et autres fonctionnalités), et non pas simplement en réduisant le menu de l'utilisateur à la malbouffe ou en simulant l'interface utilisateur avec Swing.
Je suppose que Sun pensait que les ISV souffriraient des limitations de Java et que toutes les nouvelles applications PC du monde fonctionneraient comme par magie sur Suns. Bien essayé. Ils ont fini par ne pas recevoir les applications ET ne pas avoir la langue qui décollait avant que nous puissions l'utiliser pour du code back-end de serveur uniquement logique.
Si les choses avaient été faites différemment, l'application locale ne serait peut-être pas morte.
Vous n'utiliserez jamais assez de langues, simplement parce que chaque langue convient le mieux à une toute petite classe de problèmes et qu'il est beaucoup trop difficile de mélanger les langues.
Exemples d'animaux domestiques: Java ne devrait être utilisé que lorsque la spécification est très bien pensée (en raison de nombreuses interdépendances, ce qui signifie refactoriser l'enfer) et lorsque vous travaillez avec des concepts concrets. Perl ne devrait être utilisé que pour le traitement de texte. C ne doit être utilisé que lorsque la vitesse l'emporte sur tout, y compris la flexibilité et la sécurité. Les paires clé-valeur doivent être utilisées pour les données unidimensionnelles, CSV pour les données bidimensionnelles, XML pour les données hiérarchiques et une base de données pour les éléments plus complexes.
Je crois que "Réécrivons le passé et essayons de corriger ce bogue en prétendant que rien n'a jamais fonctionné" est un mantra de débogage précieux dans des situations désespérées:
Supprimer les cours. Nombre de classes (méthodes de classes) dans .NET Framework gère les exceptions implicitement. C'est difficile de travailler avec une personne idiote.
Controversé à soi-même, parce que certaines choses sont mieux de ne pas être dites, ainsi vous ne serez pas peints par d'autres comme trop égoïste. Cependant, le voici:
Si c'est le cas, ça commence par moi
Ne vous inquiétez pas trop de la langue à apprendre, utilisez les poids lourds de l'industrie tels que c # ou python. Des langues comme Ruby sont amusantes dans la chambre à coucher, mais ne vous asseyez pas dans des scénarios en milieu de travail. Des langages tels que c # et Java peuvent gérer des projets logiciels de très petite à grande taille. Si quelqu'un dit le contraire, vous parlez d'un langage de script. Période!
Avant de démarrer un projet, déterminez la quantité d'échantillons de support et de code disponibles sur le réseau. Encore une fois, choisir un langage comme Ruby, qui contient très peu d’échantillons de code sur le Web par rapport à Java, ne vous causera plus de problèmes plus tard lorsque vous êtes coincé dans un problème.
Vous ne pouvez pas poster de message sur un forum et attendre une réponse pendant que votre patron vous demande comment se passe votre codage. Qu'est-ce que tu vas dire? "J'attends que quelqu'un m'aide sur ce forum"
Apprenez une langue et apprenez-la bien. Apprendre plusieurs langues peut porter des compétences et des pratiques, mais vous ne serez même pas OK pour toutes. Être bon à un. Il y a des livres entiers consacrés au Threading dans Java qui, lorsqu'on y réfléchit, ne représente qu'un seul espace de noms sur plus de 100.
Maîtrisez-en un ou soyez ok aux lots.
Une fois, j'ai vu ce qui suit d'un collègue:
égal = a.ComparerTo (b) == 0;
J'ai déclaré qu'il ne pouvait pas supposer que dans un cas général, mais il a juste ri.
C doit mourir.
Programmer volontairement en C quand une autre langue (disons D) est disponible devrait être punissable pour négligence.
Le cerveau humain est la clé principale de toutes les serrures.
Il n'y a rien dans ce monde qui puisse déplacer plus rapidement votre cerveau. Croyez-moi, ce n'est pas philosophique mais pratique. En ce qui concerne les opinions, elles sont comme sous
1) Ne jamais aller en dehors de la limite spécifiée dans le langage de programmation. Un exemple simple serait les pointeurs en C et C++. Ne les abusez pas car vous êtes susceptible d’obtenir le message DAMN SEGMENTATION FAULT.
2) Suivez toujours les normes de codage, oui, ce que vous lisez est correct. Les normes de codage s’appliquent beaucoup à votre programme, Après tout, votre programme est écrit pour être exécuté par la machine autre cerveau :)
System.Data.DataSet Rocks!
Les ensembles de données fortement typés sont meilleurs, à mon avis, que les objets DDD personnalisés pour la plupart des applications d'entreprise.
Raisonnement: nous nous mettons en quatre pour comprendre Unit of Work sur des objets personnalisés, LINQ to SQL, Entity Framework et sa complexité accrue. Utilisez un générateur de code Nice de quelque part pour générer la couche de données et l'Unité de travail repose sur les collections d'objets (DataTable et DataSet) - pas de mystère.
Vous devez savoir C pour pouvoir vous appeler un programmeur!
Tout n'a pas besoin d'être encapsulé dans sa propre méthode. Parfois, il est normal qu'une méthode fasse plus qu'une chose.
La configuration de l'enregistreur est une perte de temps. Pourquoi les avoir si cela signifie apprendre une nouvelle syntaxe, en particulier une qui échoue en silence? Ne vous méprenez pas, j'adore la bonne exploitation forestière. J'adore l'héritage des enregistreurs et ajouter des formateurs aux gestionnaires des enregistreurs. Mais pourquoi le faire dans un fichier de configuration?
Voulez-vous modifier le code de journalisation sans recompiler? Pourquoi? Si vous placez votre code de journalisation dans une classe, un fichier ou une autre classe, quelle différence cela fera-t-il?
Voulez-vous distribuer un journal configurable avec votre produit aux clients? Est-ce que cela ne donne pas trop d'informations de toute façon?
La chose la plus frustrante à ce sujet est que les utilitaires populaires écrits dans un langage populaire ont tendance à écrire de bonnes API dans le format spécifié par le langage. Ecrivez un utilitaire de journalisation Java et je sais que vous avez généré les javadocs, que je connais bien. Ecrivez une langue spécifique à votre domaine pour votre configuration d’enregistreur et qu’avons-nous? Peut-être qu'il y a de la documentation, mais où diable est-ce? Vous décidez d’une manière de l’organiser et je ne suis tout simplement pas intéressé à suivre votre pensée.
Apparemment, le mien est que Haskell a des variables . C’est à la fois "trivial" (selon au moins huit SO utilisateurs) (même si personne ne semble pouvoir se mettre d’accord sur la réponse correcte qui est correcte), et une mauvaise question même à poser (selon au moins cinq votants défavorables et quatre qui ont voté pour le fermer). Oh, et moi (et les scientifiques et mathématiciens en informatique), je me trompe, bien que personne ne puisse me fournir une explication détaillée de la raison.
"N'appelle pas les méthodes virtuelles des constructeurs". C’est seulement parfois un PITA, mais c’est le cas, car en C #, je ne peux pas décider à quel moment d’un constructeur appelle le constructeur de ma classe de base. Pourquoi pas? Le framework .NET le permet, alors quelle bonne raison y at-il de ne pas le permettre à C #?
Zut!
La bibliothèque STL C++ a une fonction tellement générale qu’elle n’est optimale pour personne.
UTILISATION DES MODELES DE CONCEPTION ET DE LA DOCUMENTATION
dans le développement web quelle est l'utilisation de ces choses jamais senti aucune utilisation de celui-ci