Есть ли веские причины для переноса одного свойства в #region в c #?

Question

Я недавно унаследовал некоторый код C #, где почти каждый элемент в файле был обернут в отдельный блок # region / # endregion - каждый класс, каждая функция, каждое свойство, каждое перечисление, но не поля.Каждый из них, в свою очередь, был заключен в «группировку» #region (например, «Свойства», «Конструктор», «Методы» и т. Д.).Существует несколько перегрузок одной функции с разными списками аргументов, но каждая из них заключена в отдельные области с одинаковым именем, а не в одну область для всех трех перегрузок.Тот, кто написал этот код, больше не является сотрудником компании, и из истории управления исходными кодами видно, что они присутствовали в первоначальной отправке, и практика продолжается в последующих версиях кода по мере добавления новых свойств и методов.

Есть идеи, почему это можно сделать?Некоторые мысли:

1. Чрезмерная функция VS (или инструмент очистки кода) автоматически вставила блоки # region / # endregion, и автор не удалил их.
2. ЕстьIDE, которая сворачивает области, но не функции, поэтому это было необходимо, чтобы получить свертывание синтаксиса.
3. Это метод заглушки структуры вашего кода перед его реализацией.

РЕДАКТИРОВАТЬ: Я выбрал ответ Джонатана, потому что это дало новую причину, почему кто-то мог сделать это.Спасибо за обсуждение!

Answer 1

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

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

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

Answer 2

Когда речь идет о неавтоматизированных свойствах, это может облегчить навигацию по коду.Например, большая часть следующего кода (внутри региона) является просто излишним пухом - который всегда выглядит одинаково (поскольку свойства действительно не должны иметь побочных эффектов).Имея одну строку с надписью «Свойство - Имя», гораздо удобнее ориентироваться.

#region Property - Name
private string _name;
/// <summary>
/// Gets or sets the name of the customer.
/// </summary>
/// <remarks>
/// This should always be the full name of the customer in the format {First Name} {Last Name}.
/// </remarks>
/// <example>
/// customer.Name = "Joe Bloggs";
/// </example>
/// <seealso cref="Customer"/>
/// <value>
/// The name of the customer.
/// </value>
public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}
#endregion

Однако, что касается «типа элемента» (Методы, Свойства, Конструкторы, Поля), я чувствую, чтокод сложнее ориентироваться;однако другие люди чувствуют, что это облегчает.

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

Answer 3

Я бы сказал, что это слишком усердно и не учитывает концепцию регионов.

Answer 4

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

Answer 5

Хорошо причины? Возможно нет.

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

Мои регионы обычно состоят из:

#region - Public Methods
#region - Private Methods
#region - Protected Methods
#region - Data Members
#region - Properties

Возможно, они использовали тип документа "автоматически сгенерированная справка", который искал регион вместо комментариев, чтобы построить "документ справки?"

Answer 6

Это чрезмерное районирование. Нет веских причин заключать каждую функцию, каждое перечисление в оператор региона.

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

Обычно я делаю такие регионы как:

   1. Constructors 
   2. Public Methods
   3. Private Methods    

1008 * Etc. *

Какая-то логическая группировка. Описанная вами область не выглядит логичной.