Работа с фигурным супом

Я программировал на C # и VB.NET в течение многих лет, но в основном на VB. Я делаю карьеру в сторону C # и, в целом, мне больше нравится C #.

Одна проблема, которую я имею, это кудрявый суп. В VB каждое ключевое слово структуры имеет соответствующее ключевое слово close, например:

Namespace ...
    Class ...
        Function ...
            For ...
                Using ...
                    If ...
                        ...
                    End If
                    If ...
                        ...
                    End If
                End Using
            Next
        End Function
    End Class
End Namespace

Тот же код, написанный на C #, очень трудно читать:

namespace ... {
    class ... {
        function ... {
            for ... {
                using ... {
                    if ... {
                        ...
                    }
                    if ... {
                        ...
                    }
                }
            }
            // wait... what level is this?
        }
    }
}

Будучи настолько привыкшим к VB, мне интересно, есть ли методика, используемая программистами c-style для улучшения читабельности и обеспечения того, чтобы ваш код попал в правильный «блок». Вышеприведенный пример относительно легко читается, но иногда в конце фрагмента кода у меня будет 8 или более уровней фигурных скобок, что потребует от меня прокрутить несколько страниц вверх, чтобы выяснить, какая фигурная скобка заканчивает интересующий меня блок в.

Поместите начальную фигурную скобку в тот же «ранг», что и конечная, например:

namespace ... 
{
    class ... 
    {
        function ... 
        {
            for ... 
            {
                using ... 
                {
                    if ... 
                    {
                        ...
                    }
                    if ... 
                    {
                        ...
                    }
                }
            }
            // It's the `function` level!
        }
    }
}

• В зависимости от вашей IDE: наведите курсор на скобку открытия / закрытия, и она выделит как эту, так и соответствующую скобку.
• Сверните блок, и он покажет вам, где он открывается / закрывается.
• Напишите меньшие блоки кода. Шутки в сторону. Проверьте Clean Code, и никогда не сталкивайтесь с этой проблемой снова (и иметь более читаемый / поддерживаемый код).

Одно замечание, следующий допустимый синтаксис c #, который может помочь вашей конкретной ситуации:

using (var type = new MyDisposable1())
using (var type2 = new MyDisposable2())
{
    /* do what you will with type2 and type2 */
}

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

if {
   ...
} // end if

while (condition) {
   ...
} // end while

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

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

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

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

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

После этого вы редко будете иметь вложение более 4-х уровней.

namespace FooNameSpace {
class Foo {

public void bar()
{
    while(true)
    {
        while(true)
        {
            break;
        }
    }
}

public void fooBar()
{
    foreach(var item in FooList)
    {
        foreach(var b in item.Bars)
        {
            if(b.IsReady)
            {
                bar();
            }
            bar();
        }
        bar();
    }
}

}}//end class, namespace

Недавно я решил попытаться формализовать два правила для конструкций управления потоком, которые в основном идут следующим образом:

• У вас не должно быть ничего, кроме необходимых конструкций потока кода
• Вы должны сделать конструкции потока кода как можно меньше

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

• Выйдите из области видимости, как только сможете (это включает область видимости циклов и функций)
• Следите за остальными, которые можно смягчить, выйдя из функции из предыдущего if и примените технику выхода из области действия, как я уже упоминал
• Отмените условные проверки, когда код внутри if больше, чем снаружи
• Код фактора внутри цикла выходит в другой метод, когда размер цикла увеличивается, чтобы скрыть остальную часть метода
• Следите за любыми областями, которые содержат только другую область видимости, например, функцию, вся область которой заполняется оператором if, не имеющим ничего, кроме if

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

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

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

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

Используйте Resharper, который поможет порекомендовать способы уменьшения вложенности. Кроме того, прочитайте книгу Боба Мартина « Чистый код» , в которой подчеркивается, что функция должна выполнять только одну вещь, и поэтому каждая функция должна быть длиной всего в полдюжины, так что вам не придется беспокоиться о таком количестве уровней вложенности.

Существует редактор для редактора, который может помочь вам по адресу: C # Outline .

Дополнение расширяет редактор VS20xx для C #, добавляя функции для свертывания, расширения и выделения вложенных блоков кода. Эти функции упрощают редактирование и чтение вложенного содержимого блоков кода, таких как if, while и т. Д.

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

Но в целом, я думаю, что потребуется некоторое время, пока вы не привыкнете к "Curly-Braces-Soup". (Кстати, мне действительно нравится это выражение. Звучит как Эпизод для Теории Большого Взрыва)

Отступы говорят вам, где вы находитесь, в обоих стилях синтаксиса. Если вы напишите в одной строке VB-программу или C # -программу, вы вскоре не сможете определить, где находится вложенный синтаксис. Машина анализирует конечные фразы блока или фигурные скобки, но людям нужен отступ.

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

В ту ушедшую эпоху цикл редактирования-компиляции-запуска мог включать в себя подготовку перфокарт с помощью перфоратора карт, а затем выстраивание в очередь на окно отправки на работу, где клерк брал перфокарты и отправлял их на машину. Позже, программист будет собирать вывод (напечатанный на бумаге) из другого окна. Если бы в программе были ошибки, вывод состоял бы только из диагностики компилятора. Когда время выполнения операции велико, добавленная стоимость набора end ifвместо просто )оправдана, если это помогает улучшить качество диагностики, потому что программист должен исправить как можно больше ошибок за одну итерацию, чтобы уменьшить количество потерянного времени итерации через окно представления работы.

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

Когда вы работаете в текстовом редакторе с поддержкой кода, который автоматически выравнивает и раскрашивает ваш код, на экране с высоким разрешением, где вы можете видеть шестьдесят или более строк, аргументы для таких неуклюжих языков больше не применяются. Вы можете постепенно редактировать и перестраивать программы так быстро, что вы можете справиться только с одной ошибкой за раз. Более того, видя одновременно большие разделы программы на экране и поддерживая правильные отступы, вы можете в первую очередь уменьшить вероятность появления ошибок вложенности такого рода. А хороший текстовый редактор программирования даже будет отмечать некоторые виды синтаксических ошибок при вводе. Более того, есть складывающиеся редакторы, которые свернут блоки программы на основе ее синтаксиса, давая «контурное» представление о ее структуре.

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

На самом деле, вам совсем не нужны конечные символы, как показывает язык Python. Идентификация может быть просто структурой. Люди уже используют отступы, чтобы понять структуру кода даже в тех языках, где машина использует конечные символы или фразы.

Если вы используете IDE, просто нажмите Crtl+ k+, Dи IDE сделает всю остальную работу.