Eu respeitosamente afirmo que preocupar-se com a ordem dos parâmetros é se preocupar com a coisa errada.

No livro do tio Bob " Código Limpo " ele defende, persuasivamente, que os métodos nunca devem ter mais de dois argumentos - e a maioria deve ter apenas um, se houver. Quando este é o caso, a encomenda é óbvia ou sem importância.

No entanto, de maneira imperfeita, estou tentando seguir o conselho do tio Bob - e isso está melhorando meu código.

Nos casos raros em que um método parece exigir mais informações, introduzindo um objeto de parâmetro é uma boa ideia. Normalmente, acho que este é o primeiro passo para a descoberta de um novo conceito (objeto) que é fundamental para o meu algoritmo.

Eu tento colocar os parâmetros IN primeiro, os parâmetros OUT em segundo lugar. Existem também algumas ordenações naturais, por ex. createPoint(double x, double y) é strongmente preferível a createPoint(double y, double x) .

Eu nunca vi uma "prática recomendada" documentada em relação a esse tópico específico, mas meu padrão pessoal é listá-los na ordem em que eles aparecerão no método para o qual estão sendo usados ou se o método for mais de um pass-through para uma camada de dados eu vou listá-los na ordem em que eles apareceriam no esquema do banco de dados ou nos métodos da camada de dados.

Além disso, quando há várias sobrecargas de um método, percebo que a maneira típica é listá-las começando com parâmetros que são comuns a todos (ou a maioria) dos métodos, com cada método diferente sendo anexado ao final de cada sobrecarga de método como:

void func1(string param) { }
void func2(string param, int param2) { }
void func3(string param, string param3) { }
void func3(string param, int param2, string param3) { }

Ordem: entrada (s), saída (s), parâmetros opcionais.

Frequentemente, eu sigo a convenção C / C ++ de colocar os parâmetros const primeiro (ou seja, os parâmetros que você passa por valor), e depois aqueles que você passa por referência. Isto pode não ser necessariamente o método correto de chamar funções, mas, se você estiver interessado em como cada compilador lida com parâmetros, dê uma olhada nos seguintes links para as regras que governam e / ou na ordem em que os parâmetros são colocados na pilha. p>

link

link

Eu costumo ir com o pedido de parâmetro "o que parece menos cético". Quanto menos vezes eu precisar ir para a definição do método / função, melhor. E é bom ter os parâmetros nomeados que são descritivos para o que eles são usados, assim quando a pequena dica aparece (VS), então fica ainda mais fácil.

Se você tiver linhas e linhas de parâmetros, convém considerar um design diferente. Dê um passo atrás e veja como você pode dividir isso em mais funções / métodos. Apenas uma ideia, mas quando eu tenho uma dúzia de parâmetros na minha função, quase sempre não é um problema de parâmetro, mas um problema de design.

Ordene de qualquer maneira que você acha que o curry provavelmente se beneficiará. Por exemplo, os parâmetros da função primeiro.

Sometimes (rarely), it seems that creating a function that takes a decent amount of parameters is the best route.

O uso de vários parâmetros geralmente é um indicador claro de que você viola o SRP nesse método. É improvável que um método que precise de muitos parâmetros faça apenas uma coisa. Excpetion pode ser uma função matemática ou um método de configuração, onde, de fato, vários parâmetros são necessários. Eu evitaria múltiplos parâmetros como o diabo evita a água benta. Quanto mais parâmetros você usar dentro de um método, maior a chance de que o método seja (muito) complexo; mais complexidade significa: mais difícil de manter e menos desejável.

However, when I do, I feel like I'm often choosing the ordering of the parameters at random. I usually go by "order of importance", with the most important parameter first.

No priniple você está escolhendo aleatoriamente . É claro que você pode pensar que o parâmetro A é mais relevante que o parâmetro B ; mas isso pode não ser o caso para os usuários de sua API, que pensam que B é o parâmetro mais relevante. Então, mesmo se você estivesse atento ao escolher o pedido - para outros, poderia parecer aleatório .

Is there a better way to do this? Is there a "best practice" way of ordering parameters that enhances clarity?

Existem várias maneiras de sair:

a) O caso trivial: não use mais de um parâmetro.

b) Como você não especificou qual idioma você escolheu, existe a chance de escolher um idioma com parâmetros nomeados . Isso é um agradável açúcar sintático que permite soltar o significado da ordem dos parâmetros: fn(name:"John Doe", age:36)

Nem toda linguagem permite tais sutilezas. Então o que então?

c) Você poderia usar um Dicionário / Hashmap / Matriz Associativa como parâmetro: por exemplo. O Javascript permitiria o seguinte: fn({"name":"John Doe", age:36}) que não está longe de (b).

d) Claro, se você trabalha com uma linguagem estaticamente tipada como Java. você poderia usar um Hashmap , mas perderia as informações do tipo (por exemplo, ao trabalhar com HashMap<String, Object> ) quando os parâmetros tiverem tipos diferentes (e precisarem transmitir).

A próxima etapa lógica seria passar um Object (se você estiver usando Java) com propriedades apropriadas ou algo mais leve como uma struct (se você escrever, por exemplo, C # ou C / C ++) .

Regra geral:

1) Melhor caso - seu método precisa do parâmetro no em tudo

2) Bom caso - seu método precisa de um parâmetro

3) Caso tolerável - seu método precisa de dois parâmetros

4) Todos os outros casos devem ser refatorados

Muitas vezes, um objeto complexo como parâmetro é melhor - uma versão pobre de parâmetros nomeados que funciona na maioria das plataformas. E abre a porta para parâmetros com comportamento para inicializar.

Para um exemplo da maioria das coisas que você não deveria fazer, você pode querer tentar ler a documentação da biblioteca padrão do PHP.

Eu geralmente os peço com o requerimento primeiro, do que por alguma medida combinada de importância e frequência de uso de acordo com um "sentimento" (pode ser visto como ORDER BY required DESC, SOME_MAGIC_FEELING(importancy,frequency) ) e não de acordo com qualquer prática específica.

Eu acho que quando você tem apenas 1-3 argumentos, a ordenação correta é óbvia e você "sente" o que é certo.

Semelhante à resposta da @Wyatt Barnetts, nada além de alguns parâmetros ou parâmetros muito explícitos para o método, eu recomendaria passar um objeto. Normalmente, isso é mais fácil de atualizar / manter, mais claro de ler e elimina a necessidade de se preocupar com o pedido . Além disso, muitos parâmetros para um método são um cheiro de código e há padrões de refatoração que você pode seguir para ajudar a corrigi-lo.

Exemplo explícito:

public int add(int left, int right)
{
  return left + right;
}

Como esse é um exemplo bem definido e a adição é comutativa (a ordem não importa), basta seguir com ela.

No entanto, se você adicionar algo mais complexo:

public SomeComplexReturnValue Calculate(int i, float f, string s, object o)
{
  // do work here
}

se tornaria:

public class SomeComplexInputForCalculation
{
  public int i; 
  public float f;
  public string s; 
  public object o;
}

public SomeComplexReturnValue Calculate(SomeComplexInputForCalculation input)
{
  // do work here
}

Espero que isso ajude ...