Должны ли «математические» функции следовать математическим обозначениям?

Я полагаю, что этот вопрос будет немедленно помечен как субъективный, но какой, по вашему мнению, лучше:

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 # делает с единицами измерения, и имеет то преимущество, что позволяет избежать таких проблем, как непреднамеренная замена давления на температуру. Трудно определить, какие аргументы должны идти, когда подпись (double, double, double)

Я предпочитаю это:

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

Другими словами, объясните значение кода в комментарии на английском языке (и в математике; это комментарии, вы можете расширять его столько, сколько нужно), но используйте описательные имена переменных, чтобы любой, кто читает единственный код, все еще мог понять это легко - особенно с большими функциями. Другая причина, по которой я бы использовал реальные слова в качестве имен переменных, заключается в том, что интерфейс намного понятнее, если вам нужно скопировать объявление функции в файл заголовка.

ИМХО, всегда лучше использовать установленную запись проблемной области, в которой вы работаете, если функция очень специфична для конкретной области. Кто-то, кто не понимает проблемную область, не имеет никакого шанса успешно поддерживать ваш код в любом случае, и для кого-то, кто знаком с доменом, длинные имена будут просто шумом, а также больше печатать для вас.

OTHO, я скажу, что я хотел бы, чтобы обычные математические обозначения были более многословными и описательными, но независимо от того, я думаю, математический код должен придерживаться математического соглашения.

Изменить: Этот ответ применяется только в том случае, если при написании формулы математически существует строгая договоренность об обозначениях. Если его нет, и вам придется объяснить, что представляют переменные в комментарии, даже если предположить, что читатель знаком с доменом, то лучше ошибиться в сторону более описательного соглашения.

Чистое мнение, но всегда используйте слова над однобуквенными символами. Если вы используете слова, все поймут; если вы используете символы, гарантированно будут следовать только эксперты в данной области. Даже тогда некоторые люди используют разные символы для одинаковых физических величин. Вам нечего терять, используя более длинные имена.

Ваша задача должна заключаться в ясности, а затем в правильности (неправильный, но понятный код легко исправляется), поэтому ваша функция должна быть написана для удобства сопровождения универсальным кодером, насколько это возможно. Комментарии к заголовку функции должны объяснять формулу и ее использование, а также описывать параметры ввода / вывода. После этого то, как выстроено тело функции, не должно иметь большого значения, если оно согласуется с комментариями заголовка.

(Я знаю, что это не обсуждение, но моё личное предпочтение было бы дать явные имена varaibles, хотя в этом случае одной строки может быть достаточно, поскольку это «чистая» функция; вызов с теми же параметрами даст тот же результат всегда, поэтому не должно быть никакой связанной с состоянием сложности, требующей объяснения)

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

Зависит от того, насколько «далеко» от бизнес-уровня находится код ... Чем дальше в стеке находится код, тем больше он направлен на реализацию абстрактной математической функции, тем больше я буду пытаться эмулировать общепринятый математические обозначения и соглашения об именах. Чем ближе к интерфейсу или бизнес-уровню, тем больше я буду соответствовать соглашениям, установленным в проблемной области.

Мне нравится думать об этом так: математики неправильно поняли короткие переменные, а физики последовали их примеру. Зачем повторять свою ошибку? Теперь мы знаем, что более длинные имена носят более описательный характер и вызывают меньше путаницы, поэтому следите за улучшениями. На более легкой ноте, я иногда пытаюсь проникнуть в более длинные переменные в мою математику, в которой все потрясены.

Правильный формат для уравнения программирования - тот, который вы все еще понимаете, не видев его шесть месяцев.

Если вы вернетесь к:

n*R*T/P;

И вы понимаете, что происходит, тогда, вероятно, все в порядке. Обычно для продвинутых формул я обыкновение помнить , что каждая часть была , если я не буду активно использовать его. Для меня:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

это гораздо лучший формат уравнений, потому что я могу легко понять каждую часть, даже если я не обязательно знаю, почему уравнение написано так, как оно есть.

Бросай монету.

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