Чи погана практика створення блоків коду?


12

У C ++ це неправильна практика створення блоків коду всередині якоїсь функції, наприклад:

    bool f()
    {
       {
           double test = 0;

           test = // some other variable outside this function, for example.

           if (test == // some value)
             return true;
       }

       {
           double test = 0;

           test = // some variable outside this function, different from the last one.

           if (test == // some value)
             return true;
       }

       return false;

    }

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

Чи погана практика вставляти блоки коду, щоб змінні виходили за межі після кожного тесту, і тоді я можу знову використовувати їх назви? Або я повинен шукати інше рішення? Слід зазначити, що я розглядав можливість використання одного і того ж набору змінних для всіх моїх тестів (і просто встановлення їх на 0 після закінчення кожного тесту), але я був вражений, що це може бути поганою практикою.


19
Якби я розкривав цей код, я б сказав вам розділити кожен з цих тестів на окремі методи ... Як наслідок, вам не потрібно використовувати кодові блоки, щоб окремо їх обшивати.
Можливо_Фактор

1
@Maybe_Factor - я згоден. Перевага окремих методів полягає в тому, що ви можете назвати кожен блок, надаючи більш читабельний код.
mouviciel

@mouviciel Не просто читабельніший код, але ще читабельніші тестові звіти!
Можливо_Фактор

@Maybe_Factor Я не згоден. Переміщення речей в окремі функції негативно впливає на те, що вони здаються невеликими багаторазовими бітами функціональності. Зберігати всю логіку функції в одному місці добре.
Майлз Рут

1
@MilesRout Це не одна логічна функція, це декілька тестових одиниць для функції, всі переповнені в одну тестову функцію. Кодові блоки проти функцій у звичайному коді - це ще одне обговорення.
Можливо_Фактор

Відповіді:


22

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

Але якщо все, що ви робите, - це отримання імені , то я б сказав, що це погана практика. Взагалі кажучи, звичайно; можуть застосовуватися особливі обставини.

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

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


10

Не погана практика створювати подібні блоки. Це, як працюють сфери.

Зазвичай це робиться при використанні RAII (Придбання ресурсів - ініціалізація), і ви хочете контролювати, коли викликаються деструктори.

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

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


Повторне використання локальних імен змінних не впливає на використання пам'яті.
кевін клайн

1
Ви не думаєте, що розумний оптимізатор може використовувати 1 місце пам'яті для двох змінних?
Роберт Анджежук

3
Так. Але це також може зробити це, якщо вони в тому ж обсязі, якщо вони не мають деструкторів.
Себастьян Редл
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.