Les fonctions «mathématiques» devraient-elles suivre la notation mathématique?

Je suppose que cette question sera immédiatement signalée comme subjective, mais laquelle pensez-vous est la meilleure:

double volume(double pressure, double n_moles, double temperature) {
  return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

ou

double volume(double P, double n, double T) {
  return n*R*T/P;
}

En d'autres termes, les fonctions qui implémentent une équation devraient-elles suivre la notation de cette équation, ou devraient-elles utiliser des noms plus verbeux?

Cela dépend de qui le lit. Si vous pouvez garantir que pour toute l'éternité, le prochain programmeur qui lit votre code est également familier avec la thermodynamique, alors oui, optez pour la version tronquée.

Mon style personnel est d'utiliser de telles variables (dont les abréviations sont communément connues dans le domaine), mais d'inclure leur description dans les commentaires.

/* P : Pressure
   V : Volume
   n : Number of moles
   R : Boltzmann constant
   T : Temperature (in K)
*/
double compute_V(double P, double n, double T) {
  return n*R*T/P;
}

Juste en le jetant, vous avez une autre option:

Volume ComputeVolume(Pressure p, Moles m, Temperature t) { ... }

Ceci est quelque peu similaire à ce que F # fait avec les unités de mesure et a l'avantage d'éviter des problèmes comme le remplacement par inadvertance d'une pression par une température. Il est difficile de voir quels arguments devraient aller là où la signature est (double, double, double)

Je préfère ça:

/* This function calculates volume using the following formula:
 *
 *     n * R * T
 * v = ---------
 *         P
 */
double volume(double pressure, double n_moles, double temperature) {
    return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

En d'autres termes, expliquez la signification du code dans le commentaire en anglais (et en mathématiques; ce sont des commentaires, vous pouvez les développer autant que nécessaire), mais utilisez des noms de variables descriptives pour que toute personne lisant le seul code puisse toujours comprendre facilement - en particulier avec des fonctions plus importantes. Une autre raison pour laquelle j'utiliserais de vrais mots comme noms de variable est que l'interface est beaucoup plus claire si vous devez copier la déclaration de fonction dans un fichier d'en-tête.

À mon humble avis, il est toujours préférable d'utiliser la notation établie du domaine problématique dans lequel vous travaillez si la fonction est très spécifique au domaine. Quelqu'un qui ne comprend pas le domaine problématique n'a aucune chance de réussir à maintenir votre code de toute façon, et pour quelqu'un qui connaît le domaine, les noms longs seront juste du bruit, ainsi que plus de frappe pour vous.

OTHO, je dirai que je souhaite que la notation mathématique conventionnelle soit parfois plus verbeuse et descriptive, mais je pense que le code mathématique devrait s'en tenir à la convention mathématique.

Edit: Cette réponse ne s'applique que s'il existe une convention très forte sur la notation lors de l'écriture mathématique de la formule. S'il n'y en a pas, et que vous devrez expliquer ce que les variables représentent dans un commentaire même en supposant que le lecteur est familier avec le domaine, alors il est préférable de pécher par excès de convention plus descriptive.

Opinion pure, mais utilisez toujours les mots sur les symboles d'une seule lettre. Si vous utilisez des mots, tout le monde comprendra; si vous utilisez des symboles, seuls les experts en la matière sont garantis de suivre. Même alors, certaines personnes utilisent des symboles différents pour les mêmes quantités physiques. Vous n'avez rien à perdre en utilisant des noms plus longs.

Votre souci doit être la clarté puis la justesse (un code incorrect mais clair est facilement corrigé) donc votre fonction doit être écrite pour être maintenable par un codeur générique autant que possible. Les commentaires d'en-tête de fonction doivent expliquer la formule et son utilisation et décrire les paramètres d'entrée / sortie. Par la suite, la disposition du corps de la fonction ne devrait pas trop d'importance tant qu'il est cohérent avec les commentaires d'en-tête.

(Je sais que ce n'est pas une discussion, mais - ma préférence personnelle serait de donner des noms explicites aux variables bien que dans ce cas, une ligne puisse suffire car c'est une fonction `` pure ''; un appel avec les mêmes paramètres donnerait le même toujours donc il ne devrait pas y avoir de complexité liée à l'état nécessitant une explication

• Concernant d'autres langages supportant l'analyse dimensionnelle, cela peut être implémenté par exemple en C ++ avec des modèles, la bibliothèque Boost Units utilise cette approche je crois.

Cela dépend de la façon dont le code est "loin" de la couche métier ... Le furthur est de retour dans la pile du code, plus il est ciblé vers la fonction mathématique abstraite est implémenté, plus j'essaierais d'émuler le généralement accepté Notation mathmatique et conventions de dénomination. Plus le front-end ou la couche métier sont proches, plus je suis conforme aux conventions établies dans le domaine problématique.

J'aime y penser de cette façon - les mathématiciens se sont trompés avec des variables courtes et les physiciens ont emboîté le pas. Pourquoi répéter leur erreur? Nous savons maintenant que les noms plus longs sont plus descriptifs et produisent moins de confusion, alors restez avec l'amélioration. Sur une note plus légère, j'essaie parfois d'intégrer des variables plus longues dans mes calculs, ce qui consterne tout le monde.

Le format correct pour une équation de programmation est celui que vous comprenez toujours après ne l'avoir pas vu pendant six mois.

Si vous revenez à:

n*R*T/P;

Et vous reconnaissez ce qui se passe, alors c'est très bien. Généralement, pour les formules avancées, je ne me souviens pas de ce qu'était chaque partie, sauf si je l'utilise activement. Pour moi:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

est un format d'équation bien meilleur spécifiquement parce que je peux facilement comprendre chaque partie, même si je ne sais pas nécessairement pourquoi l'équation est écrite telle quelle.

Lancez la pièce.

Pensez-vous également parfois à consacrer plus de temps à la façon de nommer une variable qu'à consacrer au codage lui-même?