Який можливий недолік розміщення декларацій у внутрішніх блоках, а не на початку функціонування?


9

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

Відповіді:


8

Я бачу дві основні переваги:

  • Повторне використання імен змінних з іншим типом запобігається.
  • Заздалегідь стає зрозуміло, що розпорядок потрібно переробити. Змінні вгорі досить швидко стають основним безладом, і цей безлад легко розпізнати.

Будь-який компілятор, вартий його солі, все одно оптимізує сферу застосування змінних, тому це стосується лише форматування.

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


3

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


3

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


3

Кожна мова може відрізнятися вподобанням стилю та практики. Далі випливає з JSF-AV-правил , яких Струструп вказує як стандарти кодування, які він віддає перевагу.

Правило АВ 136
Declarations should be at the smallest feasible scope

Обґрунтування цього описується як

This rule attempts to minimize the number of live variables that must be simultaneously considered. Furthermore, variable declarations should be postponed until enough information is available for full initialization

Якщо ви перебуваєте на C ++, то краще вважати оголошення змінних, коли вони вам потрібні.


3

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

Я не одна на цю думку. Ось питання, що вирішує ту саму проблему: /software/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need -відповідь тут полягає в тому, щоб оголосити їх там, де ви їх використовуєте. Така ж практика описана у книзі Роберта К. Мартіна «Чистий кодекс».

Однак якщо ви використовуєте старіший C-стандарт (C-89), ви повинні визначити локальні змінні у верхній частині функції. То, може, настанова є залишком від часів, коли використовувались С-89? Напевно, краще запитати у людини, яка написала вказівки, чому це правило все ще існує.


2

Якщо декларація міститься в пункті if, яке використовується лише рідко (якщо взагалі), але потребує багато пам’яті, слід пам’яті менше (більшу частину часу), ніж якщо ви виділяєте все на початку функції.

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

Є причини робити це обома способами.


1

Старий стандарт C 1989 року дозволяє лише оголошення змінних на початку блоку.

Тільки оскільки декларації C99 дозволені будь-де. Можливо, ваше місце ще не перейшло на C99.


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

1

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

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

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