Плохо ли называть неиспользуемую переменную одним подчеркиванием?

Часто, когда синтаксис языка требует, чтобы я назвал переменную, которая никогда не используется, я назову ее _.

На мой взгляд, это уменьшает беспорядок и позволяет мне сосредоточиться на значимых переменных в коде. Я нахожу это ненавязчивым, так что он производит эффект «с глаз долой, с ума».

Типичным примером того, где я делаю это, является именование подзапросов в 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):

Описательный: Стили именования

_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) Это практика, которая не помогает. Использование однобуквенных имен переменных - это старая школа (то есть мое первоначальное образование!). Я увижу их ... и затем добавлю комментарии, чтобы сказать, что делает код, и это плохая практика в современном мире. Я использую как можно больше длинных имен переменных, чтобы каждый, независимо от уровня программирования или знания кода, мог просто «прочитать» его почти как на английском. Использование однобуквенных имен является очень распространенной практикой для старого кода и для более старых программистов (опять же, включая меня), но это не делает его нормальным.

Чтобы избежать коллизий в пространстве имен и разрешить отладку, в случае, если имя переменной является вашей единственной подсказкой, возможно, было бы лучше назвать ее «join_ab_unused».

Вдохновленный Birfl.

Да, это плохая практика по двум причинам:

1. Префикс неиспользованной переменной с подчеркиванием не является общепринятым стандартом. Скорее всего, будут игнорироваться «непосвященные».
2. Я видел, как некоторые люди ставят префикс закрытых членов с подчеркиванием, и ваш стандарт очень запутает таких людей.

То, что вы пытаетесь сделать, - это написать код в более приятной версии SQL, в которой нет необходимости заставлять вас придумывать имя для чего-то бесполезного.

Подчеркивание почти невидимо, поэтому похоже, что вы на этом языке. Если бы в качестве идентификатора мог использоваться только пробел, он был бы идеальным, верно?

Но вы не на другом языке, и то, что вы делаете, не является чистым способом сделать расширение языка.

Это зависит от языка. В java да, это плохо и может быть опасной тенденцией к добавлению в ваш код, в основном потому, что инструменты, использующие отражение, не очень хорошо обрабатывают подчеркивание, так как они находятся вне соглашений по именованию переменных java. В питоне это тоже плохо, но не так плохо. В clojure все на 100% нормально, и на самом деле идиоматично использовать _ в качестве заполнителей в операторе let.

Помните, что каждый язык имеет свой собственный полный синтаксис и набор идиом, поэтому вы должны оценивать хорошее / плохое в терминах этих идиом, а не в абсолютных терминах.

Это было бы плохо в Perl, который использует $ _ (а иногда и _) в качестве специальной переменной.

В общем, я бы держался подальше от этого только потому, что _, кажется, определенно изменяемый язык. Если бы я увидел твой код, я бы в документации искал, что _ было, пока не понял, что это просто дурачок. Ничего плохого в DUMMY, $ DUMMY, что угодно.

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