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

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

}

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.

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.)

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 :(