Formatowanie kodu: rozkładanie funkcji na podstawie hierarchii wywołań w pliku klasy?

Sugestia z „Czystego kodu” Boba Martina każe mi drapać się po głowie. „Jeśli raz funkcja wywoła inną, powinny one być pionowo zamknięte, a osoba dzwoniąca powinna znajdować się powyżej odbiorcy”

Jak dotąd mniej więcej trzymałem się wytycznych .Net, które grupują członków klasy według typu (właściwości, lekarze, funkcje) i widoczności (public / prot. / Private). Na początku napiwek wydaje się kłopotem, ale „po prostu może działać”. Osobiście zetknąłem się z przypadkami, w których podobał mi się ten układ - łatwiejsze drążenie w dół, gdy jesteś we właściwym łańcuchu połączeń.

Pomysł wydaje się słuszny, ale inne scenariusze, takie jak „pozwól mi spojrzeć na publiczny interfejs tej klasy” mogą się pogorszyć. Może wujek Bob korzysta z małych klas i wsparcia IDE dla typów wyświetlania ...

Czy ktoś próbował tego przez dłuższy czas?

Aktualizacja: Wydaje się, że fragment kodu jest w porządku

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

}

Być może wychodzę tutaj na kończynę, ale zastanawiam się, czy narzędzie, którego używasz, ma na to wpływ. Mam na myśli edytor tekstu kontra decyzję IDE, którą muszą podjąć programiści.

W IDE masz o wiele więcej funkcji do przeglądania plików źródłowych. Zazwyczaj można uzyskać listę metod posortowanych alfabetycznie, według widoczności, a nawet zwrócić typ na pasku bocznym. Możesz także przejść do metody, jeśli masz do niej zastosowanie. Możesz także generować drzewa połączeń dla metod i drążenia w dół. Zwykle masz także potężne polecenie find, które może obsługiwać wyrażenia regularne. W tej sytuacji kolejność tworzonych metod nie ma znaczenia, ponieważ dostępne są widoki inne niż kod źródłowy.

W edytorze tekstów zazwyczaj nie masz tych funkcji - najbliższe, które będziesz mieć, to prawdopodobnie silne wyszukiwanie / zamiana. W tym miejscu będziesz chciał zwrócić większą uwagę na strukturę pliku, ponieważ nawigacja może być trudniejsza. Chcesz zminimalizować czas przewijania pliku, aby znaleźć to, czego szukasz, a spójna i logiczna kolejność metod może pomóc.

Chodzi o to, że nazywane rzeczy są mniej interesujące niż nazywanie rzeczy. Im bardziej metoda wywołuje inne metody, tym bardziej prawdopodobne jest, że metoda ta jest częścią zewnętrznego interfejsu API obiektu (w przeciwieństwie do szczegółów implementacji). Oznacza to, że zewnętrzny interfejs API klasy - metody publiczne, jeśli twój język obsługuje tę koncepcję - będzie naturalnie „chciał” znajdować się na górze pliku, ułatwiając znalezienie tych metod. I odwrotnie, funkcje pomocnicze i takie będą „chciały” znajdować się na dole pliku.

(Wyjaśniam pojęcie, nie oceniając jego skuteczności).

Jeśli przez dłuższy okres masz na myśli więcej niż kilka dni? Potem nie
. Kilka lat temu zacząłem to robić na nowym kodzie i powoli doprowadzałem się do szaleństwa, aż przestałem.

Moja osobista preferencja dla klas jest układanie

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

Ale to nie jest religijne, właściwości i metody mogą się ze sobą łączyć. Widoczność nie wchodzi w to (nie grupuję według publicznego / chronionego / prywatnego)

Mamy tu faceta, który ma ścisłą strukturę wszystkiego w pliku klasy, a wszystko jest zgrupowane razem w głównych grupach i podgrupach, wszystkie ładnie zagnieżdżone w regionach. . . Muszę przyznać, że uważam, że regiony są dziełem Szatana, a one napędzają mnie dookoła tego dziwnego kroku.

Za każdym razem, gdy otwieram jedną z jego zajęć, umieram trochę w środku :(