Должны ли ученики быть отсортированы?

Question

В новом проекте с новой командой, должны ли мы принудительно сортировать членов классов автоматически в определенном порядке (например, по модификатору и алфавиту) перед регистрацией?

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

Итак, каковы плюсы и минусы их автоматической сортировки?Это связано с конкретной средой разработки / процессом разработки / процессом сборки / языком?Что еще мы должны рассмотреть?

Изменить, чтобы получить больше ответов:

Однажды я был в проекте, где нам нужно было поддерживать несколько ветвей.Из-за неспособности RCS поддерживать это должным образом (SVN к тому времени), нам пришлось вручную перемещать классы и методы из одной ветви в другую и затем снова объединяться (большинство RCS может поддерживать отношение подмножество-надмножество только в одномнаправление).Поскольку методы могут появляться в любом месте класса в любом порядке, объединение было кошмаром.Применение автоматической сортировки элементов с самого начала позволило бы избежать многих трудностей.

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Переименование, перемещение кода, удаление зеленого кода, добавление комментариев - это то, что мне нравится видеть в сочетании с другими изменениями.Вот почему я обычно делю его на два изменения - одно, которое обновляет «макет / стиль кода», и другое, которое изменяет поведение программы.

Answer 3

В моем случае ... Я считаю полезным для заказа по уровню доступа. Я следую правилам StyleCop (.net, но действует в любом другом языке)

Открытый
Внутренний
Защищенный внутренний
Защищенный
Частное лицо

статические
нестатический

Внутри этой группы ... У меня есть некоторая случайность, но я всегда сначала ставлю такие вещи, как идентификатор или уникальный идентификатор.

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

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

Answer 4

Я считаю сортировку членов класса полезной, если она приводит к лучшей читаемости кода.Схема сортировки не должна быть слишком строгой, но достаточно строгой, чтобы улучшить читаемость кода.Я предпочитаю эту схему сортировки:

• статические поля
• поля экземпляра
• конструктор
• методы

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

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

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