As funções 'matemáticas' devem seguir a notação matemática?

Suponho que essa pergunta será imediatamente sinalizada como subjetiva, mas qual você acha que é melhor:

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

Em outras palavras, as funções que implementam alguma equação seguem a notação dessa equação ou devem usar nomes mais detalhados?

Depende de quem está lendo. Se você pode garantir que, por toda a eternidade, o próximo programador que lê seu código também esteja familiarizado com a termodinâmica, então sim, vá para a versão truncada.

Meu estilo pessoal é usar essas variáveis ​​(cujas abreviações são comumente conhecidas no campo), mas incluir sua descrição nos comentários.

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

Apenas jogando lá fora, você tem outra opção:

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

Isso é um pouco semelhante ao que o F # faz com as unidades de medida e tem o benefício de evitar problemas como substituir inadvertidamente uma pressão por uma temperatura. É difícil observar como devem ser os argumentos quando a assinatura é (duplo, duplo, duplo)

Eu prefiro isso:

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

Em outras palavras, explique o significado do código no comentário em inglês (e matemática; são comentários, você pode expandi-lo o quanto for necessário), mas use nomes de variáveis ​​descritivos para que qualquer pessoa que esteja lendo o único código ainda possa compreender facilmente - especialmente com funções maiores. Outra razão pela qual eu usaria palavras reais como nomes de variáveis ​​é que a interface é muito mais clara se você precisar copiar a declaração da função em um arquivo de cabeçalho.

IMHO é sempre melhor usar a notação estabelecida do domínio do problema em que você está trabalhando, se a função for muito específica do domínio. Alguém que não entende o domínio do problema não tem chance de manter seu código com êxito e, para alguém que esteja familiarizado com o domínio, os nomes longos serão apenas ruído e mais digitação para você.

OTHO, direi que gostaria que a notação matemática convencional fosse mais detalhada e descritiva às vezes, mas, independentemente disso, acho que o código matemático deve seguir a convenção matemática.

Editar: Esta resposta se aplica somente se houver uma convenção muito forte sobre notação ao escrever a fórmula matematicamente. Se não houver, e você teria que explicar o que as variáveis ​​representam em um comentário, mesmo assumindo que o leitor esteja familiarizado com o domínio, é melhor errar ao lado de uma convenção mais descritiva.

Opinião pura, mas sempre use as palavras sobre os símbolos de uma letra. Se você usar palavras, todos entenderão; se você usar símbolos, apenas os especialistas no assunto são garantidos. Mesmo assim, algumas pessoas usam símbolos diferentes para as mesmas quantidades físicas. Você não tem nada a perder usando os nomes mais longos.

Sua preocupação deve ser a clareza e a correção (o código incorreto, mas claro, é facilmente corrigido); portanto, sua função deve ser escrita para manutenção por um codificador genérico, na medida do possível. Os comentários do cabeçalho da função devem explicar a fórmula e seu uso e descrever parâmetros de entrada / saída. Posteriormente, como o corpo da função é disposto não deve importar muito, desde que seja consistente com os comentários do cabeçalho.

(Eu sei que isso não é uma discussão, mas - minha preferência pessoal seria atribuir nomes explícitos às variáveis, embora, neste caso, uma linha única seja suficiente, pois é uma função 'pura'; uma chamada com os mesmos parâmetros produziria o mesmo sempre para que não exista complexidade relacionada ao estado que exija explicação)

• Em outras linguagens que suportam análise dimensional, isso pode ser implementado, por exemplo, em C ++ com modelos, a biblioteca Boost Units usa essa abordagem, acredito.

Depende de quão "distante" da camada de negócios o código está ... Quanto mais o código estiver na pilha, mais ele será direcionado para a função matemática abstrata que implementa, mais eu tentaria emular o código geralmente aceito. notação matematica e convenções de nomenclatura. Quanto mais próximo do front end ou da camada de negócios, mais eu me conformaria às convenções estabelecidas no domínio do problema.

Eu gosto de pensar dessa maneira - os matemáticos erraram com variáveis ​​curtas e os físicos seguiram o exemplo. Por que repetir o erro deles? Agora sabemos que nomes mais longos são mais descritivos e produzem menos confusão, então fique com a melhoria. Em uma nota mais leve, às vezes tento colocar variáveis ​​mais longas em minhas contas, nas quais todos ficam horrorizados.

O formato correto para uma equação de programação é aquele que você ainda entende depois de não vê-lo há seis meses.

Se você voltar para:

n*R*T/P;

E você reconhece o que está acontecendo, então provavelmente está bem. Normalmente, para fórmulas avançadas, não me lembrarei do que era cada parte, a menos que eu a esteja usando ativamente. Para mim:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

é um formato de equação muito melhor especificamente, porque eu posso entender facilmente cada parte, mesmo que eu não saiba necessariamente por que a equação está escrita como está.

Atire a moeda.

Às vezes, você também gasta mais tempo pensando em como nomear uma variável do que na própria codificação?