Verwenden von Unterstrichen in Java -Variablen und Methodamen [geschlossen

Question

Selbst heutzutage sehe ich oft Unterstriche in Java -Variablen und -Methoden, ein Beispiel sind Mitgliedsvariablen (wie "M_COUNT" oder "_COUNT"). Soweit ich mich erinnere, wird die Verwendung von Unterstrichen in diesen Fällen von Sun als schlechter Stil bezeichnet.

Der einzige Ort, an dem sie verwendet werden sollten, ist in Konstanten (wie in "öffentliches endgültiges statisches int is_okay = 1;"), da Konstanten alle oberen Fall und nicht Kamelfall sein sollten. Hier sollte der Unterstrich den Code lesbarer machen.

Denken Sie, dass es schlechter Stil ist, Unterstriche in Java zu verwenden? Wenn ja (oder nicht), warum?

Answer 1

Wenn Sie jetzt keinen Code verwenden, würde ich vorschlagen, dies fortzusetzen. Wenn Ihre Codebasis es verwendet, setzen Sie das fort.

Das Größte am Codierungsstil ist Konsistenz. Wenn Sie nichts übereinstimmen müssen, sind die Empfehlungen des Sprachanbieters wahrscheinlich ein guter Ausgangspunkt.

Answer 2

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Answer 3

Regeln:

1. Tun Sie, was der Code, den Sie bearbeiten, tut
2. Wenn Nr. 1 nicht gelten, verwenden Sie Camelcase, keine Unterstriche

Answer 4

Ich glaube nicht, dass die Verwendung von _ oder m_, um die Mitgliedsvariablen anzuzeigen, in Java oder einer anderen Sprache schlecht ist. Ich meine Meinung verbessert es die Lesbarkeit Ihres Codes, da Sie ein Snippet betrachten und schnell alle Mitgliedsvariablen von Einheimischen identifizieren können.

Sie können dies auch erreichen, indem Sie die Benutzer dazu zwingen, Instanzvariablen mit "This" vorzubereiten, aber ich finde diesen schwacher Drakonier. In vielerlei Hinsicht verletzt es Trocken, da es sich um eine Instanzvariable handelt, warum sie zweimal qualifizieren?

Mein persönlicher Stil ist es, M_ anstelle von _ zu verwenden. Der Grund dafür ist, dass es auch globale und statische Variablen gibt. Der Vorteil von M _/_ ist, dass er einen Variablenbereich unterscheidet. Sie können also nicht global oder statisch wiederverwenden und stattdessen wähle ich g_ bzw. s_.

Answer 5

"Bad Style" ist sehr subjektiv. Wenn ein bestimmter Konventionen für Sie und Ihr Team funktioniert, denke ich, dass dies einen schlechten/guten Stil qualifiziert.

Um Ihre Frage zu beantworten: Ich benutze einen führenden Unterstrich, um private Variablen zu markieren. Ich finde es klar und kann Code schnell durchsuchen und herausfinden, was los ist.

(Ich benutze das fast nie "das", außer um einen Namen zu verhindern.)

Answer 6

Durch die Verwendung von 'm_' oder '_' an der Vorderseite einer Variablen erleichtert es, Mitgliedsvariablen in Methoden in einem Objekt zu erkennen.

Als Nebeneffekt wird Intellsense zuerst intellsinsens tippen;)

Answer 7

• Ich mag es, Unterstriche für (private) Instanzvariablen zu führen. Es scheint einfacher zu lesen und zu unterscheiden. Sie sind wohl Ihre Namenskonvention:
• private int _my_int; public int myInt;? _my_int? )

-Wie ich den _style davon mag und ich denke, es ist lesbar, finde ich es wohl mehr Ärger als es wert ist, da es ungewöhnlich ist und es wahrscheinlich nichts anderes in der von Ihnen verwendeten Codebasis übereinstimmt.

-Automatisierte Codegenerierung (z. B. Eclipse Generate Getters, Setzer) verstehen dies wahrscheinlich nicht, daher müssen Sie es von Hand reparieren oder mit Sonnenfinsternis genug dürfen, um ihn zu erkennen.

Letztendlich gehen Sie gegen den Rest der (Java-) WeltpreFs und haben wahrscheinlich einige Belästigungen. Und wie frühere Poster erwähnt haben, übertrifft die Konsistenz in der Codebasis alle oben genannten Probleme.

Answer 8

Es gibt einen Grund, warum die Verwendung von Unterstrichen in den alten Zeiten als schlechter Stil angesehen wurde. Wenn ein Laufzeit -Compiler etwas unerschwingliches war und Monitore mit erstaunlicher 320x240 Pixel -Auflösung einhergingen, war es oft nicht einfach, dazwischen zu unterscheiden _name und __name.

Answer 9

Es ist schön, etwas zu haben, um private und öffentliche Variablen zu unterscheiden, aber ich mag '_' in der allgemeinen Codierung nicht. Wenn ich es im neuen Code helfen kann, vermeide ich deren Verwendung.

Answer 10

Hier ist ein Verknüpfung zu Suns Empfehlungen für Java. Nicht, dass Sie diese verwenden müssen oder sogar, dass ihr Bibliothekscode allen folgt, aber es ist ein guter Start, wenn Sie von Grund auf neu gehen. Das Werkzeug wie Eclipse hat in Formatierungs- und Reinigungswerkzeugen eingebaut, mit denen Sie diesen Konventionen (oder anderen, die Sie definieren) anpassen können.

Für mich sind '_' zu schwer zu tippen :)

Answer 11

Es ist eine Mischung aus Codierungsstilen. Eine Denkschule besteht darin, private Mitglieder mit einem Unterstock vorzubereiten, um sie zu unterscheiden.

setBar( int bar)
{
   _bar = bar;
}

Anstatt von

setBar( int bar)
{
   this.bar = bar;
}

Andere verwenden Unterstriche, um eine lokale Temperaturvariable anzugeben, die am Ende des Methodenaufrufs aus dem Spielraum ausgeht. (Ich finde das ziemlich nutzlos - eine gute Methode sollte nicht so lang sein, und die Erklärung ist genau dort! Ich weiß also, dass sie aus dem Umfang ausgeht. ! Es wäre die Hölle.

Manchmal wird generierter Code Variablen mit _ oder __ vorgeworfen. Die Idee ist, dass kein Mensch dies jemals tun würde, also ist es sicher.

Answer 12

Ich denke, jeder Stil ist hässlich und daher "schlecht".

Zweifellos wurde der Code, den Sie gesehen haben, von jemandem geschrieben, der früher an einer Sprache gearbeitet hat, in der Unterstriche akzeptabel waren.

Einige Leute können sich einfach nicht an neue Codierungsstile anpassen ...

Answer 13

Der Grund, warum Menschen es tun (meiner Erfahrung nach), besteht darin, zwischen Mitgliedervariablen und Funktionsparametern zu unterscheiden. In Java können Sie eine Klasse wie diese haben:

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

Wenn Sie die Mitgliedsvariable _var1 oder m_var1 gemacht haben, hätten Sie nicht die Mehrdeutigkeit in der Funktion.

So ist es a Stil, und ich würde es nicht schlecht nennen.

Answer 14

Persönlich denke ich, dass eine Sprache nicht machen sollte Regeln über Codierungsstil. Es ist eine Frage von Vorlieben, Nutzung, Bequemlichkeit, Konzept der Lesbarkeit.
Jetzt ein Projekt muss Legen Sie die Codierungsregeln für Konsistenz hinweg fest. Sie stimmen diesen Regeln möglicherweise nicht zu, aber Sie sollten sich an sie halten, wenn Sie einen Beitrag leisten möchten (oder in einem Team arbeiten).

Zumindest sind IDEs wie ECLISPE agnostisch und ermöglichen es, Regeln wie variable Präfixe oder Suffixe, verschiedene Arten der Klammer- und Weltraummanagement usw. festzulegen dein Richtlinien.

HINWEIS: Ich gehören zu den alten Gewohnheiten von C/C ++, kodiere Java mit M_ -Präfixen für Mitgliedsvariablen (und S_ für statische) und Präfixing Booleans mit einem anfänglichen B unter Verwendung eines ersten Großbuchstabens für Funktionsnamen und Ausgleichspraien. .. Der Horror für Java -Fundamentalisten! ;-)
Lustig, das sind die Konventionen, in denen ich arbeite ... wahrscheinlich, weil der Hauptfestentwickler aus der MFC -Welt stammt! :-D

Answer 15

Es ist nur dein eigener Stil, nichts ein schlechter Code und nichts, was Code für einen guten Stil, nur unseren Code mit den anderen unterscheiden.