Чи варто повторно використовувати змінні?

Чи варто повторно використовувати змінні?

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

Тим НЕ менше, я дійсно знаю , що кращі практики в більшості випадків проти нього. Наприклад, вони кажуть, що не "переосмислюють" параметри методу.

Найкращі практики навіть є проти нулю попередніх змінних (у Java є Sonar, який видає попередження при призначенні nullзмінної, що вам не потрібно робити це для виклику смітника з Java 6. Ви не завжди можете керувати які попередження вимкнено; більшість часу увімкнено за замовчуванням.)

Ваша проблема з’являється лише тоді, коли ваші методи тривалі та виконуючи кілька завдань послідовно. Це робить код важче зрозуміти (і, таким чином, підтримувати) сам по собі. Повторне використання змінних додає до цього додаткового елемента ризику, що робить код ще складнішим для дотримання та більш схильним до помилок.

Найкраща практика ІМО - використовувати досить короткі методи, які роблять лише одне, усуваючи всю проблему.

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

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

Це залежить.

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

void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}

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

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

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

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

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

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

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

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

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

Я б сказав «НІ».

Подумайте над цим сценарієм: ваша програма вийшла з ладу, і вам потрібно розробити те, що сталося, оглянувши основний дамп ... чи бачите ви різницю? ;-)

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

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

scrote = int (scrote)

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

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

Ваш налагоджувач також може зробити болюче налагодження функції з багатьма змінними. Якщо функцію з 20 змінними важче налагодити, ніж одну з 16 змінними, ви можете розглянути можливість заміни 5 змінних на одну. ("Можна вважати" - це не те саме, що "слід завжди").

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

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

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

Ваш налагоджувач також може зробити болюче налагодження функції з багатьма змінними. Якщо функцію з 20 змінними важче налагодити, ніж одну з 16 змінними, ви можете розглянути можливість заміни 5 змінних на одну. ("Можна вважати" - це не те саме, що "слід завжди").

Добре, що одна змінна використовується в декількох місцях до тих пір, поки змінна завжди має одне і те ж призначення. Наприклад, якщо десять функціональних викликів повертають код помилки, який обробляється негайно для кожного виклику, використовуйте одну змінну, а не 10. Існує одна проблема з цим: Зазвичай компілятор скаже вам, коли ви використовуєте неініціалізовану змінну. Але тут, якщо ви прочитаєте код помилки після виклику 6, але змінна насправді не була змінена після виклику 5, ви отримаєте марні дані без попередження компілятора. Оскільки змінна була ініціалізована, з даними, які тепер марні.

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

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

Якщо ви не вдумаєтесь в опущення коду вручну або не дратуєте інших розробників.