Y a-t-il une raison d'écrire du code laconique en Java/C#/C++?
Vous êtes-vous déjà retrouvé à écrire du code laconique en Java, C# ou C++?
Si oui, pourquoi? Pensez-vous qu'il existe des situations dans lesquelles cela devrait être acceptable, compte tenu des situations dans lesquelles ces langues sont utilisées?
12 answers
Le code doit être aussi laconique que nécessaire et pas plus. :)
Remarques désinvoltes mis à part plusieurs facteurs affectent à quel point il devrait être laconique (ou autre):
-
Durée de vie.
- Souvent plus longtemps que vous ne le pensez:)
-
Probabilité de bugs.
- La probabilité dépend de beaucoup de choses, mais le codeur d'origine a un grand rôle à jouer dans ce domaine.
-
Les ordinateurs le lisent (l'analysent).
- Pas seulement le compilateur, pensez intellisense et autres.
-
Les humains le lisent
- parfois brut, parfois avec l'aide de programmes comme diff tools.
- parfois pas la même personne qui l'a écrit.
Caractéristiques de performance requises.
Toutes ces choses se combinent pour produire un ensemble de forces parfois concurrentes qui peuvent vouloir plus ou moins de verbosité.
Équilibrage de ces est la clé de l'efficacité du développement. Ce qui est le plus important dépend totalement du problème que votre logiciel essaie de résoudre.
Tout d'abord, prenons les bits faciles:
Ordinateurs.
Quand ils lisent votre code, ils sont tout à fait capables de le faire indépendamment de la verbosité. Ils peuvent être un peu plus lents, mais c'est quelque chose qui est normalement difficile à mesurer (il est peu probable que vous alliez au-delà de 1 ou deux ordres de grandeur de verbosité que le minimum possibilité théorique). Les exceptions notables sont celles où vous (ab)utilisez quelque chose comme la méta-programmation via un préprocesseur pour faire beaucoup d'expansion pour vous. Cela peut prendre un long temps lors de la compilation. Ici, vous devez décider si ce compromis en vaut la peine.
Humains.
En général, ce seront des gens avec un contexte similaire à vous et ils liront la source dans une situation similaire à celle où vous l'avez écrite. Cela signifie que si la fonction était dans un fichier / classe / module appelé Foo alors il n'est pas nécessaire d'aller mettre Foo devant les choses, l'aspect Foo doit être assez clair du contexte. Cela facilite la modification de cet aspect à l'avenir.
Les programmeurs familiers avec les idiomes du langage/style de programmation que vous utilisez seront tout à fait capables de comprendre plusieurs constructions extrêmement laconiques.
Les variables d'index de boucle appelées ' i ' par exemple sont aussi laconiques que vous pouvez obtenir mais ne sont normalement pas un problème jusqu'à ce que votre boucle devienne grand.
Ici, vous voyez une dichotomie intéressante. La valeur de laconisme est souvent proportionnelle à la complexité du bloc de code dans lequel il réside. À mesure que ce bloc devient plus laconique, les variables qu'il contient bénéficient davantage de la réduction. En écrivant du code dans des fonctions / classes avec une responsabilité limitée, il devient plus facile et plus utile de garder les choses laconiques car il y a moins de marge de confusion de la part d'un humain. Paradoxalement cela peut conduire à la nécessité que le contexte soit plus noms de méthode et de classe explicites, donc plus longs.
Durée de vie
La durée de vie et la probabilité de bogues tiennent compte de la fréquence à laquelle vous devrez lire le code ou le déboguer. De nombreux débogueurs prennent en charge les points d'arrêt à plusieurs points sur une ligne (repérant correctement où il y a deux instructions), mais certains ne le font pas. Par conséquent, des précautions doivent être prises si vous avez l'intention de rompre beaucoup pour vous assurer que vous pouvez les placer et les contrôler avec un minimum d'effort.
Si le le code a une faible probabilité de bugs mais une longue durée de vie vous avez une autre situation intéressante. La probabilité que le code soit compréhensible lorsque vous en venez à avoir besoin de le changer est beaucoup plus faible (vous aurez une mémoire pire ou peut-être même plus). Ce code gagnera donc à être légèrement moins laconique que la normale.
Performance
À l'occasion, vous devrez peut-être sacrifier une représentation compacte mais claire de quelque chose pour satisfaire un objectif de performance, peut-être vous devez bit pack par exemple, jamais une bonne chose à lire dans le code mais inévitable si vous devez tenir dans une certaine quantité de mémoire. Des Occasions comme celles-ci sont heureusement rares.
Concepts généraux
Certaines constructions de langage peuvent encourager le code laconique (propriétés automatiques, classes internes anonymes, lambdas pour n'en nommer que quelques-uns). Lorsque ces concepts ont du sens à utiliser, utilisez-les judicieusement. L'idée est qu'ils réduisent la plaque de la chaudière et exposentintention .
Si vous le faites la même chose à plusieurs reprises et avoir une certaine quantité de duplication de code envisager une fonction/classe/module partagé mais rappelez-vous que si vous devez rendre le code partagé moins clair (disons une instruction if supplémentaire ou des variables inutilisées dans l'un des chemins de code) alors vous ne pouvez pas avoir une victoire nette.
L'inférence de type est puissante mais rappelez-vous que le compilateur est parfois bien meilleur qu'un humain. Si vous dites flibble x = new flibble() alors var x = new flibble() n'est pas du tout extensible (et s'améliore à mesure que flibble grossit). Comparer avec var flibble = SomeMethodWhoseReturnTypeIsNotClear(). Le bon sens aide ici, si vous n'auriez jamais à utiliser intellisense pour le résoudre, vous devriez certainement envisager de l'utiliser.
Quelques autres règles empiriques utiles (et laconiques):
- Plusieurs actions sur une seule ligne confondent souvent les humains.
- Les effets secondaires confondent souvent les humains (++x ou x++ n'ont pas d'importance conceptuelle à moins qu'ils ne fassent partie d'une expression plus large par exemple)
- L'indentation aide la plupart des humains à déduire la structure bien plus que les crochets faire
- Les règles de préséance sont souvent "intériorisées" par les humains plutôt que mémorisées comme un ensemble de règles. Cela signifie que le bracketing inutile (pour le compilateur) peut être nocif pour la lisibilité lorsque l'idiome est commun mais utile lorsque l'utilisation n'est pas si courante.
- Logique non est souvent un seul caractère. Lorsque vous l'utilisez dans une instruction if, déterminez si elle peut être restructurée pour ne pas l'exiger. Cela peut ne pas être possible (si les contorsions résultantes au nom de la variable / méthode ou l'ordre du code l'emporte sur la suppression le laisser dans)
Cela dépend de votre définition de "laconique'.
Si vous voulez dire "court et au point", cela correspond étroitement à ma vision pour bon code.
Si vous voulez dire "cryptique", alors il y a un problème.
Cela dépend de ce que vous entendez exactement par "laconique". J'aime certainement écrireun code concis qui exprime exactement ce que je veux réaliser de la manière la plus simple possible. Par exemple, j'aime la façon dont LINQ me permet d'exprimer un pipeline de données plutôt que la "vieille" façon d'écrire des boucles pour transformer ou filtrer les collections, ou trouver la plus grande valeur, etc. C'est juste du code en double qui devrait être dans une méthode de modèle quelque part.
D'autre part, le code plus court n'est pas toujours plus lisible que le code plus long. L'opérateur conditionnel fait l'objet de controverses sur ce front. Est:
Foo x = null;
if (condition)
{
x = y;
}
else
{
x = z;
}
Plus ou moins lisible que:
Foo x = condition ? y : z;
Eh bien, si "condition", "y" et " z " sont tous assez simples, l'opérateur conditionnel gagne. Si vous devez passer par des cerceaux pour créer des expressions uniques" y "et" z " où l'exécution de plusieurs instructions serait plus lisible, alors le formulaire if/else sera probablement plus lisible.
En bref, j'écris le plus code lisible je peux. C'est souvent, mais pas toujours, un code laconique.
Essayez de toujours écrire du code clair. Parfois, le code clair est laconique, mais souvent ce n'est pas le cas.
Pourquoi? Parce que dans 6 mois, vous aurez besoin de comprendre ce que vous essayiez de réaliser. Plus vite vous pouvez le faire, mieux c'est.
Lors de l'écriture du code source réel, soyez aussi robuste que possible (sans sacrifier les performances). C'EST-À-dire:
var result = GetResultFromFoo(GetOtherResult()).DoSomeCalculation(CallAnotherMethod());
Pourrait être amusant à écrire, mais bonne chance déboguer ce meunier. Il n'y a aucun avantage, il suffit de le décomposer en ceci;
var result = GetOthereEsult();
var fooResult = GetResultFromFoo(result);
var anotherMethodResult = CallAnotherMethod();
var finalResult = fooResult.DoSomeCalculation(anotherMethodResult);
Beaucoup plus facile à déboguer.
La seule fois où je peux voir une raison d'écrire un code aussi laconique que possible, c'est si la taille du code source compte (comme dans un fichier JavaScript qui est servi des centaines de fois par seconde) ou lorsque j'essaie délibérément pour obscurcir le code, cependant, il existe généralement des logiciels qui le font pour vous. Donc, en bout de ligne, OMI, non, il n'y a vraiment pas beaucoup de raison à cela.
Sauf autres préoccupations, un code plus court est préférable, car vous pouvez en voir plus à la fois.
Rappelez-vous que le code est lu plus souvent qu'il n'est écrit, et gardez vos lecteurs à l'esprit lors de l'écriture (le lecteur pourrait même être vous). N'écrivez pas de code comme vous supposez que le lecteur est stupide, ni n'écrivez de code qui suppose que moins il y en a, mieux c'est.
Écrivez "court et au point" comme le suggère Joel Coehoorn.
J'ai trouvé que la lisibilité pour un humain est la fonctionnalité la plus importante pour le code à long terme.
La lisibilité comprend la concision, l'exactitude et la clarté d'esprit. Si vous mélangez les choses, vous confondez votre lecteur. Si votre code est clair à lire, vous n'avez pas besoin de beaucoup de commentaires. Si vous cassez des choses complexes dans des variables locales bien nommées, vous aidez énormément le lecteur tout en documentant implicitement ce que vous faites.
Un code bien écrit vous survivra. S'efforcer de la perfection:)
@j_random_hacker (impossible d'ajouter des commentaires à un commentaire)
Il m'est arrivé qu'après 6 mois, j'ai du mal à déchiffrer un morceau de code que j'ai écrit. Donc en effet, cette partie compte aussi
Je suis un grand fan de code que je peux lire. J'ai vu du code "laconique" qui ressemble à:
int af = yb;
while(af<ex){af++;af*=4;}
Il est facile de voir ce qui est fait par programme, mais CE qui est réellement fait en termes de sens est obscur. Je préfère avoir des noms de variables que je peux lire plus tard, plutôt que d'essayer d'enregistrer quelques caractères de code et d'aller avec des noms laconiques. Un bon code ne signifie pas toujours le plus court. Un bon code, c'est de bons algorithmes, une bonne documentation, une bonne maintenabilité. Je ne se soucient pas comment longtemps, le code est, s'il a toutes ces propriétés, c'est du bon code.
En supposant que vous utilisez le terme "laconique" avec la connotation "cryptique":
À moins qu'il ne s'agisse d'un concours de codage obscurci, je ne vois aucun intérêt à écrire du code laconique dans un langage compilé. J'ai peut-être écrit du code C++ laconique uniquement dans mes propres projets privés. Jamais dans le code que quelqu'un d'autre va voir.
Sinon, le code laconique (dans le sens "au point") est meilleur que le code verbeux.
Il y a un inconvénient mécanique à verbose code et nommage en java: Empreinte mémoire sous certaines JVM. Cela ne peut être qu'un problème de perception autour de la taille virtuelle du processus et des fichiers jar mappés en mémoire, mais il existe. Gros fichiers jar = = grande utilisation de la mémoire (perçue).
Vous devez probablement pousser les choses à l'extrême pour que cela soit mesurable en ce qui concerne la terseness, mais c'est un effet "réel" intéressant.
En termes de conseils réels, comme d'autres l'ont dit, écrivez bien coder d'abord, et s'inquiéter de l'optimisation plus tard.