Frage

Warum ist es schlechte Praxis Variablen in einer Zeile zu erklären?

z.

private String var1, var2, var3

statt:

private String var1;
private String var2;
private String var3;
War es hilfreich?

Lösung

Ich denke, dass es verschiedene Gründe, aber sie alle laufen auf, dass die erste ist nur weniger lesbar und fehleranfällig, da eine einzelne Zeile mehr als eine Sache zu tun.

Und das alles ohne wirklichen Gewinn, und sehen Sie mir nicht sagen, Sie zwei Zeilen gespeichert Platz finden, ist ein echter Gewinn.

Es ist eine ähnliche Sache, was passiert, wenn man

if ((foo = some_function()) == 0) {
    //do something
}

Natürlich ist dieses Beispiel ist viel schlimmer als bei Ihnen.

Andere Tipps

Meiner Meinung nach ist das Hauptziel jeden Variable, die in einer separaten Zeile wäre die Aufgabe der Version Control Tool zu erleichtern.

Wenn mehrere Variablen auf der gleichen Linie sind, riskieren Sie Konflikte für unabhängige Änderungen von verschiedenen Entwicklern haben.

In C ++:

int * i, j;

i ist vom Typ int *, j ist vom Typ int. Die Unterscheidung ist auch leicht zu übersehen.

Neben ihnen auf einer Linie mit jeder macht es einfacher, später einige Kommentare hinzufügen

In C / C ++, haben Sie auch das Problem, dass die * verwendet, um einen Zeigertyp angeben, gilt nur für die unmittelbar folgende Kennung. Also ein recht häufiger Fehler von unerfahrenen Entwicklern schreiben

int* var1, var2, var3;

und erwartet alle drei Variablen vom Typ ‚int Zeiger‘ zu sein, während für den Compiler dies als

liest
int* var1;
int var2;
int var3;

machen var1 nur einen Zeiger.

Mit separaten Linien, haben Sie die Möglichkeit einen Kommentar zu jeder Zeile hinzufügen, um die Verwendung der beschreibenden Größe (wenn nicht klar aus seinem Namen ist).

Da in einigen Sprachen, var2 und var3 in Ihrem Beispiel würde nicht werden Strings, würden sie Varianten sein (nicht typisiert).

Warum ist die schlechte Praxis? Ich glaube nicht, es ist, solange der Code noch lesbar ist.

//not much use
int i, j, k;

//better
int counter, 
    childCounter, 
    percentComplete;

Um ehrlich zu sein bin ich nicht gegen sie. Ich denke, dass seine durchaus möglich, zu einer Gruppe ähnliche Variablen auf der gleichen Linie z.

float fMin, fMax;

aber ich meiden, wenn die Variablen in keinem Zusammenhang beispiels sind.

int iBalance, iColor;

Relevanz.

Nur weil zwei Variablen vom Typ String sind, bedeutet nicht, dass sie eng miteinander verwandt sind.

Wenn die zwei (oder mehr) Variablen eng mit Funktion verbunden sind, eher dann Variablentyp, dann vielleicht könnten sie zusammen deklariert werden. das heißt nur dann, wenn es sinnvoll, für einen Leser Ihres Programms macht, um zu sehen, werden die beiden Variablen zusammen sollten sie tatsächlich platziert zusammen

Hier sind meine Gründe:

  • Ablesbarkeit, leichter zu erkennen, wenn Sie wissen, dass es nur eine auf jeder Zeile
  • Versionskontrolle, weniger intra-line Änderungen, mehr einzeilig Ergänzungen, Änderungen oder Streichungen, einfacher von einem Zweig auf einem anderen
  • fusionieren

Was ist mit dem Fall, wie:

public static final int NORTH = 0,
                        EAST = 1,
                        SOUTH = 2,
                        WEST = 3;

Ist das auch schlechte Praxis in Betracht gezogen? Ich würde das in Ordnung, wie es einige der Punkte, kontert bisherige:

  • , sie würden alle auf jeden Fall den gleichen Typ sein (in meiner statisch typisierte Java-Welt)
  • Kommentare können für jeden
  • hinzugefügt werden
  • , wenn Sie den Typ für eine sich ändern müssen, werden Sie wahrscheinlich es für alle zu tun haben, und alle vier können in einer Änderung
  • erfolgen

So in einer (wenn auch stinkende Code) Beispiel gibt es Gründe, die Sie würde das nicht tun?

Vereinbaren Sie mit edg, und auch, weil es besser lesbar und einfach für Wartung ist jede Variable auf separate Zeile zu haben. Sie sehen sofort, Art, Umfang und andere Modifikatoren und wenn Sie einen Modifikator ändern gilt es nur für die Variable, die Sie wollen -., Die Fehler vermeidet

  1. ersichtlicher du werden, wenn Version Control Tools (abgedeckt durch Michel)
  2. mehr lesbar sein für Sie, wenn Sie die einfachste Überlauf / Unter oder kompilieren Fehler und Ihre Augen konnte die offensichtliche
  3. darauf hinzuweisen,
  4. , um die gegenüberliegende (d.h.e multivariable einzeilige Erklärung) zu verteidigen weniger Profis ( „code textliche vertikale Sichtbarkeit“, das ein Singleton)

Es ist eine schlechte Praxis meist, wenn Sie können und wollen Variablen auf die Verzögerung initialisieren. Ein Beispiel, wo dies nicht so schlimm sein könnte, ist:

string a,b;
if (Foo())
{
  a = "Something";
  b = "Something else";
}
else
{
  a = "Some other thing";
  b = "Out of examples";
}

Im Allgemeinen ist es, für die Versionskontrolle und Kommentierung von anderen diskutierten Gründen, und ich würde das alle Fälle in 95% gilt. aber es gibt Situationen, in denen es Sinn macht, zum Beispiel, wenn ich Grafiken bin Codierung und ich möchte ein paar Variablen Texturkoordinaten darzustellen (immer per Konvention als s und t bezeichnet), dann die sie als

erklärt

int s, t; // Texturkoordinaten

IMHO die Lesbarkeit des Codes verbessert sowohl durch den Code zu verkürzen und durch sie explizit zu machen, dass diese beiden Variablen gehören zusammen (natürlich würden einige argumentieren, einen einzigen Punkt Klassenvariable in diesem Fall verwendet werden kann).

Beim Versuch, diese Frage https://www.interviewbit.com/ Probleme / remove-Element-from-Array /

Methode 1 gibt Memory Limit für diesen Code überschritten:

Typ 1:

int i,j;

Typ 2:

int i;
int j;

Typ 1: Gewährt Speichergrenze überschritten

int removeElement  (int* A, int n1, int B) 
{
    int k=0, i;
    for(i=0;i<n1;i++)
        if(A[i]!=B)
        {
            A[k]=A[i];
            k++;
        }    
    return k;
}

Während Typ-2-Werke völlig in Ordnung

int removeElement  (int* A, int n1, int B) 
{
    int k=0;
    int i;
    for(i=0;i<n1;i++)
        if(A[i]!=B)
        {
            A[k]=A[i];
            k++;
        }    
    return k;
}
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top