未使用の変数に単一の下線を付けることは悪い習慣ですか？
言語の構文で、決して使用されない変数に名前を付ける必要がある場合は、_という名前を付けます。
私の考えでは、これにより混乱が減り、コード内の意味のある変数に集中できます。私はそれが「目立たない、心の外」効果を生み出すように控えめであると思います。
これを行う一般的な例は、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
説明的な名前がコードに何も追加しないと感じた場合にのみ、このテクニックを非常に控えめに使用します。ある意味で、覚える名前を追加することでそれを取り除きます。いくつかの点で、C＃のvarキーワードと同様に見ていますが、これも控えめに使用しています。
私の同僚は同意しません。彼らは、単一の（アルファベットの）文字名であっても_よりも優れていると言っています。
私が間違っている？これを行うのは悪い習慣ですか？
すべての名前は意味がある必要があります。 _は、あなたの会社やより広いコミュニティでよく知られている標準でしたが、「重要ではない名前」として意味があります。そうでない場合、それは悪い習慣だと思います。特に将来的に名前が重要になる可能性があるため、参照する内容には説明的な名前を使用してください。
それは許容できる慣行だと思います。これは、私が過半数が間違っていると考え、最近のプログラミングのアイデアに関する知識を更新する必要があるまれな例です。多くの言語、特にHaskellやOCamlなどのMLベースの関数型言語では、_を「未使用」の変数として使用することが非常に一般的です。明示的な言語サポートを提供していないLuaでさえ、慣例により_をプレースホルダーとして使用することを推奨しています。
いくつかの言語（Haskell、Lua、DIは頭から考える）でも、アンダースコアで始まる変数が_を最短にする "未使用のローカル変数"に関するコンパイラ警告を生成しない規則を提供しています未使用の変数名。 _unusedのようなものを使用することもできますが、それが混乱するだけであることに同意します。
これは、このコードが存在するエコシステムに依存します。_が「ダミー変数」/「未使用の出力」を示すための受け入れられる標準である場合は、必ずそれに固執してください。そうでない場合は、何であるかを調べて使用します。
一部のプログラミング言語（Haskellなど）では、この「特別な」識別子が構文に組み込まれており、まさにあなたが言及した目的に使用されます。
注意してください、_は一部の言語ではすでに本質的な意味を持っています
Pythonの場合：
ここにリンクの説明を入力してください 「プライベート」インスタンス変数は、オブジェクト内からのみアクセスでき、Pythonには存在しません。ただし、ほとんどのPythonコード：アンダースコアが前に付いた名前（_spamなど）が後に続く規則があります）は、APIの非公開部分として扱われる必要があります（それが関数、メソッド、またはデータメンバー）実装の詳細と見なされ、予告なく変更される場合があります。
PEP 8（Pythonコードのスタイルガイド））にも別の記述があります：
_single_leading_underscore：弱い「内部使用」インジケーター。例えば。 from 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言語はこのキーワードを使用して、変数が関数の複数の戻り値の1つの宛先ではないことを示します。言語が複数の戻り値を持たない場合、それは必要ありません。命名規則により、_を標準の言語表記として使用する言語を使用する日が悪くなります。
（わからないPython：この構成は本当に必要ですか？）
構文的には有効で、標準の一部としては問題ないかもしれません。
そうは言っても、コードレビューで誰かに変更を依頼することになるでしょう。また、それをコーディング標準に入れることは決してせず、既存の標準から削除しようとします。読むのがもっと難しく、あまり意味がありません。
私はそれが間違っていると思います：
1）ピクセル数が少ないため、見づらい。
2）複数ある場合_、どれをどのようにして知っていますか？ -または、新しい開発者が「ルールを守り」、その使用を非常にローカルな範囲に保ったことはありますか？
3）それは役に立たない習慣です。 1文字の変数名を使用するのはとても古い方法です（つまり、私の最初の教育です）私はそれらを見ます...そして、コードが何をするかを言うために追加されたコメントを見て、それは今日の世界では悪い習慣です。私は、長い変数名をできるだけ使用するので、プログラミングレベルやコードの知識に関係なく、誰もが英語のように「読む」ことができます。 1文字の名前を使用することは、古いコードや古いプログラマー（これも私も含みます）では非常に一般的な方法ですが、それでは問題があります。
名前空間の衝突を回避し、デバッグを可能にするために、その変数名が唯一の手がかりである場合は、「joined_ab_unused」と呼ぶ方がよい場合があります。
Birflに触発されました。
はい、これは2つの理由で悪い習慣です。
- 未使用の変数の前にアンダースコアを付けることは、広く受け入れられている標準ではありません。 「初心者」はおそらく無視されます。
- プライベートメンバー変数にアンダースコアを付けた人がいますが、あなたの標準はすごくそのような人々を混乱させます。
あなたがやろうとしていることは、役に立たないものに名前を付けることを強制するという問題のない、より良いバージョンのSQLでコーディングすることです。
下線はほとんど見えないので、その言語にいるように見えます。空白だけを識別子として使用できるとしたら、それは完璧でしょう。
しかし、あなたは別の言語ではなく、あなたがしていることは言語拡張をするためのきれいな方法ではありません。
言語によって異なります。 Javaでは、これは悪いことであり、コードに追加するのは危険な傾向になる可能性があります。主に、リフレクションを使用するツールは、アンダースコアを適切に処理しないためです（アンダースコアはJava変数の命名規則pythonでは、これも悪いですがそれほど悪くはありません。clojureでは、100％正常であり、実際、 letステートメントのプレースホルダーとして_を使用します。
各言語には独自の構文全体とイディオムのセットがあるため、絶対的な用語ではなく、これらのイディオムに関して良い/悪いを評価する必要があることに注意してください。
これは、特殊変数として$ _（場合によっては_）を使用するPerlでは悪いことです。
一般に、_が言語の特定のメタ変数であるように見えるからといって、それを避けたいと思います。私があなたのコードを見た場合、それが単なるダミーであることに気づくまで、私は_が何であったかを探しているドキュメントにいるでしょう。 DUMMY、$ DUMMY、何でも問題ありません。
特定の言語またはフレームワークで頻繁に使用される他の何かを示す傾向がないことが確実でない限り、varsの先頭にあるアンダースコアは避けます。たとえば、Pythonでは、二重の下線は魔法の変数を示す傾向があります。 JQueryおよびその他のJSライブラリでは、単一の下線は、名前空間の上書きのフォールバック変数を示す傾向があります。これは、インクルードファイルの一般的な命名規則でもあり、var形式のインクルードを処理するコードに引き継がれる傾向があります。