Як ви зазвичай компонуєте регіони класу?

Мені було цікаво, чи існує стандарт для розміщення регіонів класу.

Я зараз використовую

Fields
Constructor
Properties
Public Methods
Private Methods

Fieldsбути приватною власністю та Propertiesбути публічною. Зазвичай я буду використовувати підрегіони в межах цього, якщо потрібно, або інколи додаватиму інші регіони нижче (наприклад, інтерфейс або baseClass).

Переліки, пов'язані з класом, або періодично створюються / класи чистих даних (вище фактичного визначення класу)

--- Визначення класу ---

Приватні члени

CTOR / DTOR, якщо мова має DTORs

Громадські властивості

Утилітні методи (приватні або захищені методи з малим масштабом)

Функціональність класу (може бути поділена на кілька регіонів залежно від сфери класу).

Підрегіони? Чи має ваш клас єдину відповідальність ? (мається на увазі в тому, що моя відповідь: "Рідко будь-які регіони, за винятком, можливо, групування властивостей, конструкторів та методів" ... але навіть тоді я не дуже його використовую)

Я просто хотів підтвердити, що ви маєте на увазі "#regions", а не макет класу взагалі.

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

Я уникаю регіонів. Мені подобається бачити код, з яким я працюю. Якщо вам важко знайти те, що ви шукаєте, тоді використовуйте складання коду та групуйте схожі конструкції класів разом.

Чому я ненавиджу регіони? CTRL+M,Lі CTRL+M,Oпереключить складання коду. Однак при руйнуванні він приховує весь регіон. Мені потрібно лише згортати методи / властивості / коментарі.

Якщо регіонів занадто багато, можливо, його код запах, і ваш клас робить занадто багато роботи. Джефф Етвуд пропонує хороший пост у регіонах, який варто прочитати.

Моя улюблена цитата на #regions:

Ні, я не буду використовувати #regions. І ні, я НЕ СПРАВУЮТЬ З ТЕРРИСТИКАМИ. Заткнися.

- Джефф Етвуд

Попри це, я знаю, що багато програмістів наполягають на їх використанні. Це питання є суб'єктивним. Я просто думав, що запропоную альтернативу.

Він варіюється від мови до мови. Оскільки я кодер Delphi, я схильний дотримуватися стандартної конвенції Delphi, яка виглядає приблизно так:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

Я вважаю хорошим способом організувати інформацію, яку легко читати та розуміти.

Я схильний їх викладати таким чином:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

Не використовував мову, яка використовує Properties, тому вони не викладені. Я розміщую приватні методи та поля внизу, тому що якщо хтось інший використовує цей файл у своєму коді, їм слід лише стосуватися API, який є загальнодоступним. І всі текстові редактори, про які я знаю, і навіть IDE встановлюють курсор вгорі під час відкриття файлів.

Це заклик суду для мене. Я використовую регіони, коли вони потрібні для читання.

Я також використовую інший колір у своїй кольоровій гамі Visual Studio (зараз темно-червоний), щоб вони виділялися з решти коду.

Приклад того, де я можу використовувати #region: Якщо я напишу метод тесту для одиничного тесту, який вимагає багаторядкового фрагмента XML, рядок XML порушить звичайний відступ (оскільки він починається уздовж лівої межі поля вікно коду. Щоб приховати неподобство, я загорну його в #region, щоб я міг його згортати.

Книга « Чистий код» Боб Мартіна присвячує форматуванню всю п'яту главу. Є кілька ключових моментів, які, як мені здається, це добре підсумовують.

• Більшість спроб групувати змінні та методи за видимістю та чистотою Не має великого сенсу, і змушує вас багато орієнтуватися навколо коду.
• Утримання методів, які дзвонять один одному вертикально, зменшує кількість навігації, яку вам потрібно зробити, і полегшує пошук речей.
• Ваш потяг думок не буде порушений, якщо вам доведеться зупинитися і подумати, "до якого регіону належить цей біт коду?" кожні кілька хвилин.
• Змінні екземплярів, як правило, мають бути небагато, і, ймовірно, будуть використовуватися всюди, тому вони належать у верхній частині класу, де їх буде найлегше знайти. Змінні та декларації, які будуть використовуватися лише одним методом, повинні існувати всередині цього методу. Якщо вони використовуються лише декількома методами, то вони повинні бути вертикально близькими, але вище кількох методів, які їх використовують.

Якщо ваш код розташований з елементами, що взаємодіють між собою, вертикально близько один до одного, ефективно усуває будь-яку необхідність у створенні конкретних регіонів. Якщо ваш код настільки довгий, що вимагає, щоб регіони приховували багато коду, можливо, це запах коду, який вказує на те, що клас намагається зробити занадто багато. Можливо, частина функціональних можливостей може бути перенесена в клас корисності або пересунута на предка.

Якщо вам потрібно "приховати" код, оскільки він занадто довгий або занадто "некрасивий", то, мабуть, у вас виникнуть більші проблеми, ніж використовувати регіони чи ні. Особисто мені ніколи не потрібно їх використовувати, і коли я працюю над чужим кодом, я вважаю, що мені завжди потрібно все-таки відкрити їх, так навіщо турбуватися?

В даний час я розміщую такі класи:

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

а потім префікс рівня доступу до кожної декларації (сортування, іноді групування за доступом). Раніше я групував верхній рівень за доступом, але в якийсь момент я не знаю, коли це не спрацювало так само, як вище. Наприклад, в C ++ / CLI (який я змушений використовувати на даний момент :-() ви можете це зробити, що заплутує групування за доступом:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

Лунатична бахрома відповідає: Мені це не принаймні, якщо мова йде про C #. Між Visual Studio та R # я магічно можу перейти до будь-якого учасника чи впровадження, щоб не було жодного сенсу нав’язуватися щодо цього матеріалу; просто почніть вводити місце, де знаходиться курсор.

Як і Wyatt та ще кілька відповідей, я також взагалі уникаю використання регіонів. Регіони мають одну мету; щоб приховати код, який ви не хочете шукати. Якщо у вас дуже багато коду в класі, на який ви не хочете дивитися, і тому вам потрібно багато регіонів, щоб дозволити згортання згаданого коду, то, ймовірно, у вас занадто багато коду в класі. ReSharper не поважає регіони, коли вирішує, де розмістити новий код, якщо тільки він не створив регіон (що він робить для реалізації інтерфейсу).

Єдине використання регіонів, які я вважаю прийнятним, - це приховати "неминуче негарний" код; код, який стосується конкретних деталей впровадження, які не можуть бути добре зосереджені у відповідності до діючих стандартів. Це, як правило, розширений езотеричний код, який, як правило, не повинен переплутати середній молодший програміст після написання. Це такі речі, як:

• Деякі вбудовані інтерфейсні реалізації (IDisposable, IConvertible, іноді IEnumerable або IComparable, оскільки їм потрібні загальні та негенеричні реалізації)
• Вбудовані зовнішні елементи P / Invoke та споріднені структури.
• Фіналізатори / деструктори (зазвичай постачаються з IDisposable)
• Гачки для керованої пам'яті / покажчиків / "небезпечних" код.