Чи повинні "математичні" функції слідувати математичним позначенням?

Я припускаю, що це питання буде негайно позначено як суб'єктивне, але, на вашу думку, краще:

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

або

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

Іншими словами, чи повинні функції, що реалізують якесь рівняння, слідувати позначенню рівняння, або вони повинні використовувати більше багатослівних імен?

Залежить від того, хто її читає. Якщо ви можете гарантувати, що на всю вічність наступний програміст, який читає ваш код, також знайомий з термодинамікою, тоді так, перейдіть до усіченої версії.

Мій особистий стиль - використовувати такі змінні (скорочення яких загальновідомі в цій галузі), але включати їх опис у коментарях.

/* 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;
}

Просто викинувши його, у вас є ще один варіант:

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

Це дещо схоже на те, що F # робить з одиницями вимірювання, і має перевагу уникнути таких проблем, як заміна ненавмисного тиску температурою. Важко окуляру, які аргументи повинні бути, куди, коли підпис (подвійний, подвійний, подвійний)

Я вважаю за краще це:

/* 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;
}

Іншими словами, поясніть значення коду в коментарі англійською мовою (і математика; це коментарі, ви можете розширити його наскільки це необхідно), але використовуйте описові назви змінних, щоб кожен, хто читає єдиний код, все-таки міг зрозуміти це легко - особливо з більшими функціями. Ще одна причина, чому я використовую реальні слова як імена змінних, - це те, що інтерфейс набагато зрозуміліший, якщо вам потрібно скопіювати декларацію функції у файл заголовка.

IMHO завжди краще використовувати встановлене позначення проблемного домену, в якому ви працюєте, якщо функція дуже доменна. Хтось, хто не розуміє проблемний домен, не має шансів успішно зберегти ваш код, а для тих, хто знайомий з доменом, довгі імена будуть просто шумом, а також більше набиратимуть вас.

ДРУГО, я скажу, що я хотів би, щоб звичайні математичні позначення були часом більш багатослівними та описовими, але незалежно від того, я думаю, математичний код повинен дотримуватися математичної конвенції.

Редагувати: Ця відповідь застосовується лише в тому випадку, якщо математична написання формули є дуже сильною умовою щодо нотації. Якщо такого немає, і вам доведеться пояснити, що представляють змінні в коментарі, навіть припускаючи, що читач знайомий з доменом, тоді краще помилитися на стороні більш описової конвенції.

Чиста думка, але завжди використовуйте слова над однолітерними символами. Якщо ви вживаєте слова, всі зрозуміють; якщо ви використовуєте символи, гарантовано дотримуватимуться лише експерти з предметів. Вже тоді деякі люди використовують різні символи для однакових фізичних величин. Вам немає чого втрачати, використовуючи довші імена.

Ваша турбота повинна бути чіткістю, а потім правильністю (неправильний, але чіткий код легко виправляється), тому ваша функція повинна бути написана для ремонтопридатності загальним кодером, наскільки це можливо. Зауваження до заголовка функції повинні пояснювати формулу та її використання та описувати параметри введення / виводу. Згодом спосіб розміщення функції функції не повинен мати великого значення, якщо він відповідає коментарям заголовка.

(Я знаю, що це не дискусія, але - моє особисте перевагу було б давати чіткі імена змінним, хоча в цьому випадку однолінійного може бути достатньо, оскільки це "чиста" функція; дзвінок з тими ж параметрами дав би те саме результат завжди, тому не повинно бути пов'язаних з державою складностей, які потребують пояснення)

• Що стосується інших мов, що підтримують розмірний аналіз, це може бути реалізовано, наприклад, у C ++ за допомогою шаблонів, я вважаю, що бібліотека Boost Units використовує такий підхід.

Залежить від того, наскільки "далеко" від бізнес-шару знаходиться код ... Чим надалі в стеку є код, тим більше націлений він на реалізацію абстрактної математичної функції, тим більше я б намагався наслідувати загальноприйнятого математичні позначення та називання конвенцій. Чим ближче до переднього кінця чи до бізнес-шару, тим більше я відповідав би умовам, встановленим у проблемній області.

Мені подобається думати про це так - математики помилялися з короткими змінними, а фізики йшли за цим. Навіщо повторювати їх помилку? Зараз ми знаємо, що довші назви є більш описовими та створюють менше плутанини, тому дотримуйтесь вдосконалення. Що стосується легшої ноти, я іноді намагаюся прокрасти її довші змінні у мою математику, на яку всі здивовані.

Правильний формат рівняння програмування - це той, який ви все ще розумієте, не бачивши його протягом півроку.

Якщо ви повернетесь до:

n*R*T/P;

І ви визнаєте, що відбувається, то, мабуть, це добре. Зазвичай для розширених формул я не пам’ятаю, що було кожною частиною, якщо я активно не використовую її. Для мене:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

є набагато кращим форматом рівнянь, тому що я легко розумію кожну частину, навіть якщо я не обов'язково знаю, чому рівняння написано таким, яким воно є.

Киньте монету.

Ви також інколи витрачаєте більше часу на роздуми над тим, як назвати змінну, ніж витрачаєте на саме кодування?