Справа з фігурним брекет-супом

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

Одна з проблем, які у мене є, - це кучерявий суп з брекетів. У VB кожне ключове слово структури має відповідне ключове слово, наприклад:

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 для поліпшення читабельності та забезпечення того, щоб ваш код опинився у правильному "блоці". Наведений вище приклад порівняно легко читати, але іноді в кінці фрагмента коду у мене буде 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

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

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

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

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

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

Є редактор, який може допомогти вам за адресою: C # Контур .

Додаток розширює редактор VS20xx для C #, додаючи функції для згортання, розширення та виділення вкладених блоків коду. Ці функції дозволяють легше редагувати та читати вкладені вмісти блоків коду, наприклад, якщо, поки тощо.

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

Але в цілому я думаю, що це просто пройде деякий час, поки ти не звикнеш до "Кучерявих брекетів-супів". (Btw, мені дуже подобається цей вираз. Звучить трохи як назва епізоду для теорії великого вибуху)

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

Фрази, що закінчуються блоком, походять з епохи перфокарт та паперової стрічки, коли програмування було набагато менш інтерактивним та наочним. Або, справді, зовсім не інтерактивним. Вводити програми було важко, тому програмістам потрібні компілятори, щоб вони були дуже розумні щодо аналізу синтаксису та відновлення помилок.

У ту епоху, що минула, цикл редагування-збирання міг включати підготовку перфокарт із картографічним перфоратором, а потім вишикуватися до вікна подання на роботу, де діловод взяв пробиті картки та подав їх до машини. Пізніше програміст збирає вихід (надрукований на папері) з іншого вікна. Якщо в програмі були помилки, вихід складається з просто діагностики компілятора. Коли час повороту тривалий, додаткова вартість набору тексту end ifзамість просто )виправдана, якщо це сприяє поліпшенню якості діагностики, оскільки програмісту потрібно виправити якомога більше помилок за одну ітерацію, щоб зменшити кількість витрат часу ітерації через вікно подання завдання.

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

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

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

Насправді, символи закінчення вам зовсім не потрібні, як це демонструє мова Python. Ідентифікація може бути просто структурою. Люди вже використовують відступи, щоб упорядкувати структуру коду навіть у мовах, де машина покладається на кінцеві символи чи фрази.

Якщо ви використовуєте IDE, просто натисніть Crtl+ k+, Dі IDE виконає решту робіт.