Formatação de código: definindo funções com base na hierarquia de chamadas em um arquivo de classe?

10

Uma sugestão do "Código Limpo" de Bob Martin me faz coçar a cabeça. "Se uma função chamar outra, ela deverá estar verticalmente próxima e o chamador deve estar acima do chamado"

Até agora, tenho me aproximado mais ou menos das diretrizes .Net, que agrupam os membros da classe por tipo (propriedades, ctors, funções) e visibilidade (public / prot. / Private). A dica parece um problema no começo ... mas "pode ​​funcionar". Pessoalmente, encontrei casos em que gostei desse layout - mais fácil de detalhar quando você está na cadeia de chamadas correta.

A ideia por trás da dica parece sólida, mas outros cenários como "deixe-me ver a interface pública desta classe" podem piorar. Talvez o tio Bob esteja apostando nas classes pequenas e no suporte a IDE para visualizar tipos ...

Alguém já tentou isso por um período prolongado?

Atualização: parece que um trecho de código está em ordem

class SomeType()
{
  /// fields, ctors, et. all
  public void Method1()   { // calls HelperMethod1 and HelperMethod2 }
  private void HelperMethod1 { // calls HelperMethod3 }
  private void HelperMethod3 {}
  private void HelperMethod2 {}

  public void Method2 () { // and so on... }

}
Gishu
fonte
2
O horrível "tio Bob" não é exatamente o lápis mais afiado da caixa.
Neil Butterworth
11
A idéia é apenas "me dê uma visão geral antes dos detalhes minuciosos". Adapte conforme necessário.
Ryan Culpepper
2
Os Eagles devem estar chegando perto de se reunir novamente, porque me encontro concordando com o comentário de Neil. Eu cresci com o PASCAL e "coloquei as pequenas coisas em primeiro lugar" porque os compiladores do PASCAL exigiam que todas as coisas fossem definidas antes de serem referenciadas, e as declarações FORWARD eram geralmente desaprovadas.
John R. Strohm
@ Neil - Estou tentando julgar o mérito do conselho .. independentemente da fonte. @ John - e a dica é o oposto das declarações de encaminhamento. Você coloca o chamador em primeiro lugar. Os 'destinatários são declarados logo abaixo dos chamadores.
Gishu
@ryanc - o prelúdio desse parágrafo enfatiza que os conceitos "estreitamente relacionados / coesos" devem estar juntos verticalmente [impede a rolagem quando você está tentando descobrir alguma coisa]. As funções chamadas são dispostas abaixo do chamador na ordem das chamadas. Veja trecho de código adicionado
Gishu

Respostas:

2

Eu posso estar estressado aqui, mas me pergunto se a ferramenta que você usa tem impacto nisso. Estou me referindo ao editor de texto versus a decisão do IDE que os desenvolvedores devem tomar.

Em um IDE, você tem muito mais funcionalidade para exibir arquivos de origem. Normalmente, você pode obter uma lista dos métodos classificados em ordem alfabética, por visibilidade ou até mesmo retornar um tipo em uma barra lateral. Você também pode pular para um método se tiver um uso para ele. Você também pode gerar árvores de chamada para métodos e detalhar. Você também costuma ter um poderoso comando find que pode suportar expressões regulares. Nessa situação, a ordem dos métodos que você cria realmente não importa, pois você tem visualizações diferentes do código-fonte disponível.

Em um editor de texto, você normalmente não possui esses recursos - o mais próximo que você terá é provavelmente uma forte localização / substituição. Aqui, você deve prestar mais atenção à estrutura do seu arquivo, pois pode ser mais difícil navegar. Você deseja minimizar o tempo gasto percorrendo o arquivo para encontrar o que está procurando, e uma ordem lógica e consistente de métodos pode ajudar.

Thomas Owens
fonte
+1 para o IDE; melhor o IDE, menos um tem que se preocupar com tais coisas
user281377
1

O ponto é que as coisas chamadas são menos interessantes do que chamar as coisas. Quanto mais um método chama outros métodos, maior a probabilidade de ele fazer parte da API externa do objeto (em vez de ser um detalhe de implementação). Isso significa que a API externa da classe - métodos públicos, se o seu idioma suportar esse conceito - naturalmente "desejará" estar no topo do arquivo, facilitando a localização desses métodos. Por outro lado, as funções auxiliares e essas "quererão" estar na parte inferior do arquivo.

(Estou explicando o conceito, não avaliando sua eficácia.)

Frank Shearar
fonte
Sim, mas isso implicaria que todas as funções públicas deveriam flutuar na parte superior do arquivo como um grupo viz. abordagem convencional. A abordagem proposta é diferente (ou pelo menos como eu a leio). Veja a atualização em questão
Gishu
Sim, de fato, suas funções públicas devem flutuar para o topo. É claro que algumas línguas não têm modificadores de visibilidade em tudo ...
Frank Shearar
1

Se por período prolongado você quer dizer por mais de alguns dias? Então não.
Alguns anos atrás, comecei a fazer isso em algum código novo e lentamente me enlouqueci até parar.

Minha preferência pessoal por organizar aulas é

class MyClass
{
    // static fields
    // fields
    // constructors
    // properties
    // methods
} 

Mas isso não é religioso, propriedades e métodos podem se misturar. A visibilidade não aparece (não agrupo por público / protegido / privado)

Temos um cara aqui no escritório que mantém uma estrutura rigorosa sobre tudo em um arquivo de classe, com tudo agrupado nos principais grupos e subgrupos, todos bem aninhados nas regiões. . . Eu tenho que admitir que acho que as regiões são obra de Satanás, elas me conduzem ao redor da maldita reviravolta.

Toda vez que abro uma de suas aulas, morro um pouco por dentro :(

Preocupação binária
fonte
Não estou defendendo grandes aulas com regiões adicionadas para mascarar o cheiro. Não tentando ser religioso ... mas ter um layout consistente dentro de um projeto acelera as coisas - saber para onde procurar. Agrupamento visibilidade bu como o benefício adicional de ter a API pública juntos para que você possa encontrar o seu ponto de entrada específica e detalhamento de lá ...
Gishu
E construtores? Aqueles vão sob "métodos"?
Cody Grey
@Cody Gray: Desculpas, esqueci os médicos!
Preocupação binária
@ Gishu: Acho que as ferramentas modernas de visualização e navegação removeram a necessidade de layouts de arquivo estritos. Importa onde um método é implementado quando posso clicar com o botão direito do mouse no uso e em "Ir para a definição"?
Preocupação binária