Порядок членов класса в исходном коде

Question

Это было задано ранее (вопрос № 308581) , но этот конкретный вопрос и ответы немного специфичны для C ++, и многие вещи не очень актуальны в таких языках, как Java или C #.

Дело в том, что даже после рефакторизации я обнаружил, что в моих файлах исходного кода есть небольшая путаница. Я имею в виду, с телами функций все в порядке, но я не совсем доволен тем, как упорядочены сами функции. Конечно, в IDE, такой как Visual Studio, относительно легко найти члена, если вы помните, как он называется, но это не всегда так.

Я испробовал несколько подходов, таких как размещение открытых методов первым, но недостаток этого подхода заключается в том, что функция вверху файла в конечном итоге вызывает другую закрытую функцию внизу файла, поэтому я получаю прокрутка все время.

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

Итак, учтите следующее: ваш код был реорганизован должным образом, чтобы он соответствовал всем требованиям, указанным в Code Complete , но вы все равно хотели бы изменить порядок своих методов для эргономических целей . Какой у тебя подход?

(На самом деле, хотя это не совсем техническая проблема, эта проблема действительно меня бесит, поэтому я был бы очень признателен, если бы кто-то смог придумать хороший подход)

Answer 1

На самом деле я полностью полагаюсь на навигационные функции моей IDE, то есть Visual Studio. Большую часть времени я использую F12 для перехода к объявлению (или Shift-F12 для поиска всех ссылок) и Ctrl + - для возврата назад.

Причина в том, что большую часть времени я работаю над кодом, который сам не написал, и не хочу тратить свое время на переупорядочение методов и полей.

P.S .: И я также использую RockScroll , надстройку VS, которая упрощает навигацию и прокрутку больших файлов

Answer 2

Если у вас действительно возникают проблемы с прокруткой и поиском, возможно, вы страдаете от синдрома класса бога.

Fwiw, лично я склонен идти с:

class
{
  #statics (if any)

  #constructor

  #destructor (if any)

  #member variables

  #properties (if any)

  #public methods (overrides, etc, first then extensions)

  #private (aka helper) methods (if any)
}

И я не испытываю отвращения к блокам регионов или комментариям, поэтому свободно использую оба для обозначения отношений.

Answer 3

Я помещаю самый последний метод, который я только что создал, в класс. Таким образом, когда я открываю проект, я возвращаюсь к последнему разрабатываемому методу. Мне легче вернуться «в зону».

Это также отразило тот факт, что метод (который использует другие методы), который я только что создал, является верхним слоем других методов.

Группируйте связанные функции вместе, не стесняйтесь ставить все частные функции внизу. Аналогично, имитируя обоснование дизайна свойств C #, связанные функции должны находиться в непосредственной близости друг от друга, языковая конструкция C # для свойств усиливает эту идею.

---

Постскриптум
Если только C # может вкладывать такие функции, как Pascal или Delphi. Возможно, Андерс Хейлсберг может написать это на C #, он также изобрел Turbo Pascal и Delphi :-) D язык имеет вложенные функции.

Answer 4

Мой заказ, вот он.

• Я обычно ставлю статики на первое место.

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

• Третий - это конструктор (или конструкторы, если их несколько).

• После этого следуйте методикам. Они упорядочены по тому, что кажется логичным для этого конкретного класса. Я часто группирую методы по уровню доступа: приватный, защищенный, публичный. Но недавно у меня был класс, который должен был переопределить множество методов из своего базового класса. Поскольку я там много работал, я собрал их в одну группу, независимо от уровня доступа.

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

В C # я использую #region, чтобы отделить эти группы друг от друга, но это дело вкуса. Есть много людей, которым не нравятся регионы. Я делаю.

Answer 5

С моей (Java) точки зрения, я бы сказал, конструкторы, открытые методы, частные методы, в таком порядке. Я всегда стараюсь группировать методы, реализующие определенный интерфейс, вместе.

Мое любимое оружие выбора - IntelliJ IDEA, у которого есть несколько хороших возможностей для сворачивания тел методов, поэтому довольно просто отобразить два метода друг над другом, даже если их фактическое положение в исходном файле составляет 700 строк.

Я был бы осторожен с изучением положения методов в фактическом источнике. Ваша IDE должна дать вам возможность просматривать источник так, как вы хотите. Это особенно актуально при работе над проектом, где разработчики могут использовать свою IDE по своему выбору.

Answer 6

Мой личный подход к структурированию класса следующий:

Я строг с

• константы и статические поля сначала, в альфа-порядке
• не приватные внутренние классы и перечисления в альфа-порядке
• поля (и атрибуты, где это применимо), в альфа-порядке
• ctors (и dtors, где это применимо)
• статические методы и фабричные методы
• методы ниже, в альфа-порядке, независимо от видимости.

Я всегда использую возможности автоформатирования IDE. Поэтому я постоянно нажимаю Ctrl+Shift+F, когда работаю. Я экспортирую возможности автоформатирования в XML-файл, который я всегда ношу с собой.

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

Я не утверждаю МОЙ ПУТЬ - это путь. Но выберите что-то, настройте это, используйте это последовательно, пока это не станет рефлексом, и таким образом забудьте об этом.

Answer 7

Я почти уверен, что был надстройка Visual Studio, которая могла бы переупорядочить участников класса в коде.

, то есть ctors в верхней части класса, затем статические методы, затем экземпляры методов ... что-то в этом роде

к сожалению, я не могу вспомнить название этого дополнения! Я также думаю, что это дополнение было бесплатно! может быть, кто-то другой может помочь нам?

Answer 8

Несколько лет назад я потратил слишком много времени на размышления над этим вопросом и придумал ужасно сложную систему для упорядочения объявлений внутри класса. Порядок будет зависеть от спецификатора доступа, является ли метод или поле статическим, временным, изменчивым и т. Д.

Это того не стоило. ИМХО, вы не получите никакой реальной выгоды от такого сложного соглашения.

То, что я делаю сейчас, намного проще:

1. Конструкторы (сначала конструктор по умолчанию, иначе порядок не имеет значения.)
2. Методы, отсортированные по имени (статические и нестатические значения не имеют, ни абстрактные, ни конкретные, виртуальные и конечные и т. Д.)
3. Внутренние классы, отсортированные по имени (интерфейс и класс и т. Д. Не имеет значения)
4. Поля, отсортированные по имени (статические и нестатические значения не имеют.) Сначала необязательно константы (public static final), но это необязательно.