Ist es eine schlechte Praxis, eine nicht verwendete Variable mit einem einzelnen Unterstrich zu benennen?

Wenn ich aufgrund der Syntax der Sprache eine Variable benennen muss, die nie verwendet wird, werde ich sie oft benennen _.

In meinen Augen reduziert dies die Unordnung und ermöglicht es mir, mich auf die aussagekräftigen Variablen im Code zu konzentrieren. Ich finde es unauffällig, so dass es einen "out of sight, out of mind" -Effekt erzeugt.

Ein häufiges Beispiel dafür, wo ich das mache, ist das Benennen von Unterabfragen in 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

Ein weiteres Beispiel ist eine nicht verwendete Schleifenvariable.

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

Ich benutze diese Technik sehr sparsam, nur wenn ich das Gefühl habe, dass ein beschreibender Name dem Code nichts hinzufügt und ihn in gewisser Weise durch Hinzufügen weiterer zu merkender Namen aufhebt. In gewisser Weise sehe ich es ähnlich wie das varSchlüsselwort in C #, das ich auch sparsam verwende.

Meine Mitarbeiter sind anderer Meinung. Sie sagen, dass sogar ein einzelner (alphabetischer) Zeichenname besser ist als _.

Liege ich falsch? Ist es schlechte Praxis, dies zu tun?

Alle Namen sollten aussagekräftig sein. Wenn dies _in Ihrem Unternehmen oder in der breiteren Gemeinschaft ein bekannter Standard wäre, wäre dies als "Name, der keine Rolle spielt" sinnvoll. Wenn nicht, würde ich sagen, es ist schlechtes Training. Verwenden Sie einen aussagekräftigen Namen für das, worauf Sie sich beziehen, zumal der Name in Zukunft eine Rolle spielen könnte.

Ich würde sagen, dass es eine akzeptable Praxis ist. Dies ist ein seltener Fall, in dem ich die Mehrheit für falsch halte und ihr Wissen über die neuesten Programmierideen auf den neuesten Stand bringen muss. In vielen Sprachen, insbesondere in ML-basierten funktionalen Sprachen wie Haskell und OCaml, ist die Verwendung _als "unbenutzte" Variable äußerst verbreitet . Selbst Lua, die keine explizite Sprachunterstützung bietet, empfiehlt die Verwendung _als Platzhalter gemäß Konvention.

Einige Sprachen (Haskell, Lua und DI denken über den Kopf) bieten auch eine Konvention, bei der Variablen, die mit einem Unterstrich beginnen, keine Compiler-Warnungen über "nicht verwendete lokale Variable" generieren, wodurch _der kürzeste nicht verwendete Variablenname entsteht. Sie könnten so etwas gebrauchen, _unusedaber ich stimme Ihnen zu, dass es nur Unordnung macht.

In Python _ist definitiv akzeptabel. Es kann jedoch zu einem Konflikt mit dem gettextAlias ​​kommen _().

Andere gängige Konventionen sind dummy, unused; allein oder als Präfix.

Einige Codeanalyse-Tools kennen diese Konventionen und geben keine Warnungen für nicht verwendete Variablen aus:

• PyLint für _oderdummy
• PyDev für jede Variable ab _, unusedoderdummy

Es hängt von dem Ökosystem ab, in dem dieser Code leben wird. Wenn _es sich um einen akzeptierten Standard handelt, der "Dummy-Variable" / "nicht genutzte Ausgabe" angibt, bleiben Sie auf jeden Fall dabei. Wenn nicht, finden Sie heraus, was ist und verwenden Sie das.

Einige Programmiersprachen (z. B. Haskell) haben sogar diesen speziellen Bezeichner in ihrer Syntax für genau die Zwecke, die Sie erwähnen.

Achtung, _ hat in einigen Sprachen bereits eine intrinsische Bedeutung

In Python:

9.6. Private Variablen und klassenlokale Referenzen

Geben Sie hier eine Linkbeschreibung ein. Auf „Private“ Instanzvariablen, auf die nur innerhalb eines Objekts zugegriffen werden kann, ist in Python kein Zugriff möglich. Es gibt jedoch eine Konvention, die von den meisten Python-Codes befolgt wird: Ein Name mit einem vorangestellten Unterstrich (z. B. _spam) sollte als nicht öffentlicher Teil der API behandelt werden (unabhängig davon, ob es sich um eine Funktion, eine Methode oder ein Datenelement handelt). . Es sollte als Implementierungsdetail betrachtet werden und kann ohne vorherige Ankündigung geändert werden.

Es gibt auch eine weitere Erwähnung in PEP 8 (Style Guide for Python Code):

Beschreibend: Benennen von Stilen

_single_leading_underscore: schwacher Indikator für "internen Gebrauch". ZB aus M import * importiert keine Objekte, deren Name mit einem Unterstrich beginnt.

In C #:

Es wird im Allgemeinen verwendet, um private Variablen mit öffentlichen / internen Eigenschaften zu markieren. Aber die Praxis wird heutzutage allgemein herabgeschaut .

In JavaScript:

Es gibt eine Bibliothek mit dem Namen underscore.js, die den Unterstrich als Präfix für nicht standardmäßige Prototyperweiterungen verwendet.

Beispiel:

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

Was mich zu meinem Punkt führt. Was stimmt nicht mit den klassischen Konventionen für Platzhaltervariablen?

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

Warum sollten Sie eine benutzerdefinierte Konvention verwenden, die einige möglicherweise falsch interpretieren, wenn bereits viele gängige Konventionen verfügbar sind?

Ich benutze "Dummy" für solche Sachen. Oder "Mist", wenn ich nur etwas ausprobiere :) Nennen Sie Ihre Variablen, um zu beschreiben, was sie sind. Wenn es sich um Dummy-Variablen handelt, die nicht verwendet werden, benennen Sie sie als solche.

Ich finde es schlecht, weil

• Sie sollten keine unsichtbare Variable in Ihrem Code haben. Wenn Sie der Meinung sind, dass Sie sollten, könnte der Grund wahrscheinlich besprochen werden.

• Die Sprache Go verwendet dieses Schlüsselwort, um anzugeben, dass keine Variable das Ziel einer der mehreren Rückgaben einer Funktion ist. Wenn Ihre Sprache nicht mehrere Rückgaben hat, wird sie nicht benötigt. Ihre Namenskonvention wird Sie an dem Tag verletzen, an dem Sie eine Sprache verwenden, die _ als Standardnotation verwendet.

(Ich kenne Python nicht. Wird dieses Konstrukt wirklich benötigt?)

Es kann syntaktisch gültig und als Teil eines Standards in Ordnung sein.

Vor diesem Hintergrund würde ich jemanden bitten, die Codeüberprüfung zu ändern. Ich würde es auch niemals in einen Kodierungsstandard einbauen und versuchen, es aus einem existierenden zu entfernen. Es ist nur schwieriger zu lesen und nicht sehr aussagekräftig.

Ich denke, es ist falsch, weil:

1) Es ist schwerer zu erkennen, da es nicht viele Pixel gibt.

2) Wenn es mehr als eine gibt _, woher weißt du welche? - oder dass ein neuer Entwickler "die Regeln befolgt" und ihre Verwendung äußerst lokal gehalten hat?

3) Es ist eine Praxis, die nicht hilfreich ist. Die Verwendung von Variablennamen mit einem Buchstaben ist so altmodisch (dh meine ursprüngliche Ausbildung!). Ich werde sie sehen ... und dann werden Kommentare hinzugefügt, um zu sagen, was der Code tut, und das ist eine schlechte Praxis in der heutigen Welt. Ich benutze so oft wie möglich lange Variablennamen, damit jeder, ungeachtet der Programmierebene oder der Vertrautheit mit dem Code, ihn fast wie Englisch "lesen" kann. Die Verwendung von 1-Buchstaben-Namen ist eine äußerst häufige Praxis mit älterem Code und mit älteren Programmierern (schließt mich wieder ein), aber das macht es nicht ok.

Um Namespace-Kollisionen zu vermeiden und das Debuggen zu ermöglichen, ist es möglicherweise besser, den Variablennamen als "join_ab_unused" zu bezeichnen.

Inspiriert von Birfl.

Ja, es ist aus zwei Gründen eine schlechte Praxis:

1. Das Präfixieren einer nicht verwendeten Variablen mit einem Unterstrich ist kein allgemein akzeptierter Standard. Es wird wahrscheinlich der "Uneingeweihte" ignoriert.
2. Ich habe einige Leute gesehen, die privaten Mitgliedsvariablen einen Unterstrich voranstellen , und Ihr Standard würde solche Leute sehr verwirren.

Was Sie versuchen, ist Code in einer schöneren Version von SQL zu schreiben, die Sie nicht zwingt, einen Namen für etwas Nutzloses zu erfinden.

Der Unterstrich ist fast unsichtbar, sodass Sie anscheinend in dieser Sprache sprechen. Wenn nur Whitespace als Bezeichner verwendet werden könnte, wäre es perfekt, oder?

Aber Sie sprechen keine andere Sprache und was Sie tun, ist keine saubere Möglichkeit, eine Spracherweiterung vorzunehmen.

Das hängt von der Sprache ab. Ja, in Java ist dies schlecht und ein gefährlicher Trend, der Ihrem Code hinzugefügt werden kann, vor allem, weil Tools, die Reflektion verwenden, Unterstriche nicht sehr gut verarbeiten, da sie außerhalb der Namenskonventionen für Java-Variablen liegen. In Python ist das auch schlecht, aber nicht so schlecht. In der Regel ist es zu 100% in Ordnung, und in der Tat ist es idiomatisch, _s als Platzhalter in einer let-Anweisung zu verwenden.

Denken Sie daran, dass jede Sprache ihre eigene Syntax und ihren eigenen Satz von Redewendungen hat. Sie müssen also gut / schlecht in Bezug auf diese Redewendungen und nicht in absoluten Werten bewerten.

Dies wäre schlecht in Perl, das $ _ (und manchmal _) als spezielle Variable verwendet.

Im Allgemeinen würde ich mich davon fernhalten, nur weil das _ eine Sprache zu sein scheint, die spezifisch für eine Variable ist. Wenn ich Ihren Code sehen würde, würde ich in der Dokumentation nach dem suchen, was _ ist, bis mir klar wird, dass es nur ein Dummy ist. Nichts ist falsch mit DUMMY, $ DUMMY, was auch immer.

Ich würde Unterstriche am Anfang von Variablen vermeiden, es sei denn, Sie waren sich sicher, dass sie in einer bestimmten Sprache oder einem stark genutzten Framework nicht dazu tendieren, etwas anderes anzuzeigen. In Python weist beispielsweise ein doppelter Unterstrich tendenziell auf eine magische Var hin. In JQuery- und anderen JS-Bibliotheken weist ein einzelner Unterstrich tendenziell auf eine Ausweichvariable für das Überschreiben von Namespaces hin. Es ist auch eine beliebte Namenskonvention für Include-Dateien, die wiederum dazu neigen, Code zu übertragen, der Include-Dateien in Var-Form verarbeitet.