# регион / # endregion против подфункций?

Question

Как вы рекомендуете использовать #region / #endregion? В какой степени это должно заменить использование подфункций для уточнения вашего кода?

Answer 1

Совсем нет.

Прежде всего, #regions - это скорее способ группировки многих связанных функций / членов в складывающиеся области. Они не предназначены для структурирования одной функции из нескольких тысяч строк в части. (Это, как говорится, если вы пишете один метод, который так долго, что вы думаете о структурировании его с #region s, то вы, вероятно, делаете что-то серьезно неправильно. Регионы или нет, этот код будет не поддерживаемым.

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

Answer 2

#region / #endregion - это способ логически сгруппировать части кода, принадлежащие одному и тому же классу. Лично я склонен группировать объявления частных полей, свойства, публичные и частные функции.

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

Answer 3

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

Использовать регион.

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

Answer 4

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

Я думаю (надеюсь, молюсь), что обстоятельства этого кодекса - крайний случай. Константы C #, основанные на объявлении типа VB3, которое определяет, как устроена структура данных COBOL, возвращаемая функцией C ++. Да, я перенес это на Python. Я так хорош. Я испытываю желание выучить Haskell только , чтобы я мог переписать в нем свой код Python, с надеждой на то, что однажды будет реализован мой код на Haskell в OCaml.

    #region buffer_definition
    /*
        The buffer is a byte array that is passed to the underlying API.  The VB representation of
        the buffer's structure (using zero-based arrays, so each array has one more element than
        its dimension) is this:

        Public Type BUFFER_TYPE
            Method As String * 50
            Status As Integer
            Msg As String * 200
            DataLine As String * 1200

            Prop(49) As String * 100

            Fld(79) As String * 20
            Fmt(79) As String * 50
            Prompt(79) As String * 20
            ValIn(79) As String * 80
            ValOut(79) As String * 80
        End Type

        The constants defined here have the following prefixes:
            len = field length
            cnt = count of fields in an array
            ptr = starting position within the buffer
    */

    // data element lengths
    private const int len_method = 50;
    private const int len_status = 2;
    private const int len_msg = 200;
    private const int len_dataLine = 1200;

    // array elements require both count and length:
    private const int cnt_prop = 50;
    private const int len_prop = 100;

    private const int cnt_fld = 80;
    private const int len_fld = 20;
    private const int len_fmt = 50;
    private const int len_prompt = 20;
    private const int len_valIn = 80;
    private const int len_valOut = 80;

    // calculate the buffer length
    private const int len_buffer =
        len_method
        + len_status
        + len_msg
        + len_dataLine
        + (cnt_prop * len_prop)
        + (cnt_fld * (len_fld + len_fmt + len_prompt + len_valIn + len_valOut));

    // calculate the pointers to the start of each field.  These pointers are used
    // in the marshalling methods to marshal data into and out of the buffer.
    private const int PtrMethod = 0;
    private const int PtrStatus = PtrMethod + len_method;
    private const int PtrMsg = PtrStatus + len_status;
    private const int PtrDataLine = PtrMsg + len_msg;
    private const int PtrProp = PtrDataLine + len_dataLine;
    private const int PtrFld = PtrProp + (cnt_prop * len_prop);
    private const int PtrFmt = PtrFld + (cnt_fld * len_fld);
    private const int PtrPrompt = PtrFmt + (cnt_fld * len_fmt);
    private const int PtrValIn = PtrPrompt + (cnt_fld * len_prompt);
    private const int PtrValOut = PtrValIn + (cnt_fld * len_valIn);

    [MarshalAs(UnmanagedType.LPStr, SizeConst = len_buffer)]
    private static byte[] buffer = new byte[len_buffer];

    #endregion

Answer 5

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

Программисты любят порядок; большинство людей любят убирать вещи в маленькие коробочки. Они группируют беспорядочный код, поля, свойства, конструкторы, методы, публичные методы, внутренние методы, приватные методы, вспомогательные методы, константы, реализации интерфейса, и Бог знает, что еще.

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

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

Одно поле? Полевой регион! Два свойства? Недвижимость в регионе! Один конструктор? Строитель региона! Один частный метод? Частный метод регион!

Я мог бы продолжить.

По сей день я все еще поражаюсь, когда вижу это. В некоторых случаях область, пустая строка, другая пустая строка и конечная область могут занимать 5-кратное пространство исходного кода (5 строк с областями, 1 строка без). Это в основном форма ОКР; эти регионы могут апеллировать к нашему чувству порядка во время написания программного обеспечения, но на практике они бесполезны - чистый шум. Когда я впервые начал писать на C #, я тоже злоупотреблял ими. Но потом я понял, насколько шумным был мой код, и что нажатие ctrl-k l каждый раз, когда я открываю файл, является признаком того, что я делал это неправильно.

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

Время от времени я все еще использую регионы, но ... я проявляю большую сдержанность.

Answer 6

Если у вас более одной «логической группы кода» в классе, ваш класс нарушает принцип единой ответственности.

Разберитесь, и вам больше не нужны регионы.