¿Deberían las funciones 'matemáticas' seguir la notación matemática?

Supongo que esta pregunta se marcará de inmediato como subjetiva, pero ¿cuál crees que es mejor?

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

o

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

En otras palabras, ¿deberían las funciones que implementan alguna ecuación seguir la notación de esa ecuación, o deberían usar nombres más detallados?

Depende de quién lo lea. Si puede garantizar que por toda la eternidad, el próximo programador que lea su código también esté familiarizado con la termodinámica, entonces sí, elija la versión truncada.

Mi estilo personal es usar tales variables (cuyas abreviaturas se conocen comúnmente en el campo), pero incluir su descripción en los comentarios.

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

Solo arrojándolo, tienes otra opción:

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

Esto es algo similar a lo que F # hace con unidades de medida, y tiene el beneficio de evitar problemas como reemplazar inadvertidamente una presión por una temperatura. Es difícil observar qué argumentos deberían ir cuando la firma es como (doble, doble, doble)

Prefiero esto:

/* 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 otras palabras, explique el significado del código en el comentario en inglés (y matemáticas; son comentarios, puede ampliarlo tanto como sea necesario), pero use nombres de variables descriptivas para que cualquiera que lea el único código aún pueda comprender es fácil, especialmente con funciones más grandes. Otra razón por la que usaría palabras reales como nombres de variables es que la interfaz es mucho más clara si necesita copiar la declaración de función en un archivo de encabezado.

En mi humilde opinión, siempre es mejor usar la notación establecida del dominio del problema en el que estás trabajando si la función es muy específica del dominio. Alguien que no entienda el dominio del problema no tiene ninguna posibilidad de mantener con éxito su código de todos modos, y para alguien que esté familiarizado con el dominio, los nombres largos serán solo ruido, además de escribir más para usted.

OTHO, diré que desearía que la notación matemática convencional fuera más detallada y descriptiva a veces, pero independientemente creo que el código matemático debería apegarse a la convención matemática.

Editar: esta respuesta se aplica solo si hay una convención muy fuerte sobre notación al escribir la fórmula matemáticamente. Si no hay ninguno, y tendría que explicar qué representan las variables en un comentario incluso suponiendo que el lector esté familiarizado con el dominio, entonces es mejor errar al lado de una convención más descriptiva.

Opinión pura, pero siempre use las palabras sobre los símbolos de una letra. Si usa palabras, todos lo entenderán; Si utiliza símbolos, solo los expertos en la materia tienen la garantía de seguirlo. Incluso entonces, algunas personas usan símbolos diferentes para las mismas cantidades físicas. No tiene nada que perder usando los nombres más largos.

Su preocupación debe ser la claridad y la corrección (el código incorrecto pero claro se corrige fácilmente), por lo tanto, su función debe ser escrita para que un codificador genérico la pueda mantener en la medida de lo posible. Los comentarios del encabezado de la función deben explicar la fórmula y su uso y describir los parámetros de entrada / salida. A partir de entonces, la disposición del cuerpo de la función no debería importar demasiado, siempre que sea coherente con los comentarios del encabezado.

(Sé que esto no es una discusión, pero mi preferencia personal sería dar nombres explícitos a los objetos valiosos, aunque en este caso podría bastar una frase ya que es una función 'pura'; una llamada con los mismos parámetros produciría el mismo resultado siempre, por lo que no debería haber complejidad relacionada con el estado que requiera explicación)

• En otros lenguajes que admiten análisis dimensionales, esto se puede implementar, por ejemplo, en C ++ con plantillas, la biblioteca Boost Units utiliza este enfoque, creo.

Depende de cuán "lejos" de la capa empresarial esté el código ... Cuanto más atrás esté en la pila el código, cuanto más dirigido esté hacia la función matemática abstracta se implementa, más trataría de emular lo generalmente aceptado Notación matemática y convenciones de nomenclatura. Cuanto más cerca del front-end o de la capa empresarial, más me conformaría con las convenciones establecidas en el dominio del problema.

Me gusta pensar de esta manera: los matemáticos se equivocaron con variables cortas y los físicos hicieron lo mismo. ¿Por qué repetir su error? Ahora sabemos que los nombres más largos son más descriptivos y producen menos confusión, por lo que debemos seguir mejorando. En una nota más ligera, a veces trato de introducir variables más largas en mis matemáticas, con lo cual todos están horrorizados.

El formato correcto para una ecuación de programación es uno que todavía entiendes después de no haberlo visto durante seis meses.

Si vuelves a:

n*R*T/P;

Y reconoces lo que está sucediendo, entonces probablemente esté bien. Por lo general, para fórmulas avanzadas, no recordaré qué era cada parte a menos que la esté usando activamente. Para mi:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

es un formato de ecuación mucho mejor específicamente porque puedo entender fácilmente cada parte, incluso si no necesariamente sé por qué la ecuación está escrita tal como está.

Lanza la moneda.

¿A veces también pasa más tiempo pensando en cómo nombrar una variable de lo que gasta en la codificación en sí?