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

Часто, коли синтаксис мови вимагає, щоб я назвав змінну, яка ніколи не використовується, я буду називати її _.

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

Поширений приклад того, як я це роблю, - іменування підзапитів у SQL.

SELECT *
FROM
(
    SELECT *
    FROM TableA
    JOIN TableB
        ON TableA.ColumnB = TableB.ColumnB
    WHERE [ColumnA] > 10
) _ --This name is required, but never used here
ORDER BY ColumnC

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

array = [[] for _ in range(n)] # Defines a list of n empty lists in Python

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

Мої колеги не згодні. Вони кажуть, що навіть мати єдине (алфавітне) ім'я символів краще, ніж _.

Я помиляюся? Чи погано це робити?

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

Я б сказав, що це прийнятна практика. Це рідкісний випадок, коли я вважаю, що більшість є помилковими та потребують оновлення своїх знань про останні ідеї програмування. У багатьох мовах, зокрема функціональних мовах на основі ML, таких як Haskell і OCaml, надзвичайно часто використовувати _як "невикористовувану" змінну. Навіть Lua, який не пропонує явної мовної підтримки для неї, заохочує використання _як заповнювача за умовами.

Кілька мов (Haskell, Lua та DI придумують верхню частину моєї голови) також пропонують умову, коли змінні, що призводять до підкреслення, не генерують попередження компілятора про "невикористану локальну змінну", що робить _найкоротше невикористане ім'я змінної. Ви можете використати щось на кшталт, _unusedале я згоден з вами, що це просто захаращує.

У Python _, безумовно, прийнятний. Однак він може конфліктувати з gettextпсевдонімом _().

Інші загальні конвенції є dummy, unused; поодинці або як префікс.

Деякі інструменти аналізу коду відомі цим умовам і не видають невикористаних попереджень змінних:

• PyLint для _абоdummy
• PyDev для будь-якої змінної , починаючи з _, unusedабоdummy

Залежно від екосистеми, в якій цей код буде жити. Якщо _прийнятим стандартом для позначення "фіктивної змінної" / "невикористаного виводу", то, будь-ласка, дотримуйтесь цього. Якщо це не так, з’ясуйте, що є, і використовуйте це.

Деякі мови програмування (наприклад, Haskell) навіть мають цей "спеціальний" ідентифікатор, вбудований у їх синтаксис саме для тих цілей, які ви згадуєте.

Обережно, _ вже має внутрішнє значення в деяких мовах

На Python:

9.6. Приватні змінні та місцеві класи

введіть опис посилання сюди "Приватні" змінні екземпляра, до яких не можна отримати доступ, за винятком усередині об'єкта, не існує в Python. Однак існує умова, за яким дотримується більшість кодів Python: ім'я з префіксом підкреслення (наприклад, _spam) слід трактувати як непублічну частину API (будь то функція, метод чи член даних) . Це слід розглянути деталі реалізації та підлягати змінам без попереднього повідомлення.

Також є ще одна згадка в PEP 8 (Посібник зі стилю для Python Code):

Описово: називання стилів

_single_leading_underscore: слабкий показник "внутрішнього використання". Напр. З M import * не імпортує об'єкти, ім'я яких починається з підкреслення.

В C #:

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

У JavaScript:

Існує бібліотека під назвою underscore.js, яка використовує підкреслення як префікс для нестандартних розширень прототипу.

Приклад:

var object = { some:'stuff' };
var newObject = _.clone(object);

Що призводить мене до моєї точки зору. Що не так з класичними умовами змінної заповнювача.

var i, j, k, l; // iterator placeholders
var x, y, z, xx, yy, zz // value placeholders
var foo, bar, bas, fixx, buzz, qux, etc... // demonstration placeholders

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

Я використовую "манекен" для подібних речей. Або "лайно", якщо я просто щось тестую :) Назвіть свої змінні, щоб описати, що вони є. Якщо вони манекени, невикористані змінні, назвіть їх як таких.

Я вважаю це поганою практикою, оскільки

• у вашому коді не повинно бути невидимої змінної. Якщо ви вважаєте, що слід, можливо, обговорити причину.

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

(Я не знаю Python: чи потрібна ця конструкція?)

Це може бути синтаксично дійсним, і воно може бути нормальним як частина стандарту.

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

Я думаю, що це неправильно, оскільки:

1) Це важче помітити, оскільки не так багато пікселів.

2) Якщо їх більше _, як ви знаєте, хто з них? - чи новий розробник "дотримувався правил" і зберігав їх використання вкрай локальним за обсягом?

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

Щоб уникнути зіткнень у просторі імен та дозволити налагодження, у випадку, якщо назва змінної є вашою єдиною підказкою, можливо, буде краще назвати її "joined_ab_unused".

Натхненний Бірфлом.

Так, це погана практика з двох причин:

1. Префіксація невикористаної змінної за допомогою підкреслення не є загальноприйнятим стандартом. Ймовірно, "ініційовані" будуть ігноровані.
2. Я бачив, як деякі люди вказують змінні приватних членів із підкресленням, і ваш стандарт сильно заплутає таких людей.

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

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

Але ви не з іншої мови, і те, що ви робите, не є чистим способом зробити розширення мови.

Це залежить від мови. У Java , так, це погано, і це може бути небезпечною тенденцією додавати до свого коду, значною мірою тому, що інструменти, які використовують відображення, не дуже добре підкреслюють підкреслення, оскільки вони знаходяться поза умовами імен змінної Java. У python це теж погано, але не так вже й погано. У clojure - це 100% нормально, а насправді його ідіоматично використовувати _ в якості місць, що займають місця, у висловленні let.

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

Це буде погано в perl, який використовує $ _ (а іноді і _) як спеціальну змінну.

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

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