Шаблоны для объявления функций для большей читаемости - PullRequest
Новая
       10

Шаблоны для объявления функций для большей читаемости

1 голос
/ 12 ноября 2009

В C ++ функции должны быть объявлены до их вызова. Это можно обойти с помощью сигнатур функций, но по большей части это больше не требуется в более новых языках программирования, C #, Python, ETC.

Однако, читая другие люди, код и когда приходится структурировать функции в классе, я обнаружил, что мне не хватает согласованности, которая существовала в C ++.

Какие существуют шаблоны для объявления / упорядочения функций при сохранении читабельности и понимания структуры вашего кода?

Редактировать 1

Вот грубый пример. 

class A
{
  private FunkB()
  {
    ...
  }

  private FunkC()
  {
    ...
  }

  public FunkA()
  {
    FunkB();
    FunkC();
  }

  public FunkD()
  {
    FunkC();
    ...
  }
}

* 1015 смотри выше * 

class A
{
  public FunkA()
  {
    FunkB();
    FunkC();
  }

  private FunkB()
  {
    ...
  }

  private FunkC()
  {
    ...
  }

  public FunkD()
  {
    FunkC();
    ...
  }
}

Редактировать 2

Это будет руководство для написания кода независимо от редакторов. Более новые редакторы имеют отличные функции «перейти к определению», и в этом также помогают закладки. Однако меня интересует независимый от редактора шаблон .

Ответы [ 3 ]

0 голосов
/ 24 января 2010

При чтении кода метода в отдельности, вы хотите понять цель метода. Если уровень абстракции внутри метода хороший, а имена всех других вызываемых методов имеют смысл в его контексте, вам не нужно знать их для понимания кода. Вы будете относиться к ним как к черным ящикам.

Некоторые принципы, которые помогают добиться большей читабельности в малых:

Принцип единого уровня абстракции

Принцип единой ответственности (pdf)

Составной метод

И не забывайте, всегда используйте добрые имена! Вот почему ваш пример не подходит для этого обсуждения.

0 голосов
/ 24 января 2010

Как упоминалось ранее, в любой приличной среде IDE порядок функций в файле становится гораздо менее важным. Это также особенно относится к объектно-ориентированным языкам, где другие методы навигации более полезны, чем последовательное чтение. Например: класс heirarchy; план класса; позвоните heirarchy. Если вы действительно упускаете определения функций, возможно, в языке есть что-то, что подходит для этой цели, например: чисто виртуальные классы в C ++ (если так они называются) или интерфейсы в Java.

Однако, сказав, что всякий раз, когда я реорганизую текст в исходном файле, я всегда склоняюсь к упорядочиванию функций на основе их сплоченности [1]. После этого я иду в том порядке, в котором функции родились . Если, как и в вашем примере, у меня есть функция, из которой родились другие, более мелкие вспомогательные функции, я бы поместил их ниже того места, откуда они были извлечены. Я просто нахожу более интуитивно понятным сначала прочитать то, что важно, и игнорировать мелкие детали, пока мне не нужно их знать, и, увидев сначала более крупный метод, обычно это достигается. Похоже, это больше похоже на ваш второй пример.

Подводя итог, я бы сказал: Большой, затем Маленький , или Публичные, а затем частные помощники .

[1] Это кодовый запах, если в одном классе / файле слишком много группировок, что предполагает их разделение на более мелкие отдельные блоки.

0 голосов
/ 18 ноября 2009

В IDE порядок методов, кажется, имеет для меня гораздо меньшее значение. Я не читаю весь источник, скорее, я продолжаю так: читайте метод, определяйте интересный вызов функции, просите IDE открыть объявление этой функции (которая может быть из другого источника). Или найдите интересную функцию, задайтесь вопросом, где она используется, попросите IDE перечислить ссылки.

Среда IDE обычно отображает сводный список методов в классе, сортирует его и фильтрует его различными способами, поэтому повторное сквозное чтение не требуется.

Единственное, чего я хочу, это понимания «что это за класс». В этом есть две вещи: программирование на интерфейсы и хорошая документация по классам.

Таким образом, я бы рекомендовал четко задокументированные обязанности для класса, часто выражаемые в терминах конкретных интерфейсов. Порядок методов в источнике для меня менее важен.

...