为什么不在同一行声明多个相同类型的变量?

发布于 2024-07-06 04:54:35 字数 201 浏览 9 评论 0原文

为什么在一行中声明变量是一种不好的做法?

例如

private String var1, var2, var3

,而不是:

private String var1;
private String var2;
private String var3;

Why is it bad practice to declare variables on one line?

e.g.

private String var1, var2, var3

instead of:

private String var1;
private String var2;
private String var3;

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(17

凤舞天涯 2024-07-13 04:54:35

在我看来,将每个变量放在单独的行上的主要目标是促进版本控制工具的工作。

如果多个变量位于同一行,则不同开发人员可能会因不相关的修改而发生冲突。

In my opinion, the main goal of having each variable on a separate line would be to facilitate the job of Version Control tools.

If several variables are on the same line you risk having conflicts for unrelated modifications by different developers.

因为看清所以看轻 2024-07-13 04:54:35

在 C++ 中:

int * i, j;

i 是 int * 类型,j 是 int 类型。
这种区别很容易被忽视。

除了将它们各占一行之外,以后添加一些注释也变得更加容易

In C++ :

int * i, j;

i is of type int *, j is of type int.
The distinction is too easily missed.

Besides having them on one line each makes it easier to add some comments later

谜泪 2024-07-13 04:54:35

我认为原因有很多,但都归结为第一个原因可读性较差,而且更容易失败,因为一行要做不止一件事。

所有这一切都没有真正的收获,难道你不告诉我你发现节省的两行空间是真正的收获吗?

时发生的情况类似。

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

这与当你有“当然这个例子比你的例子糟糕得多”

I think that there are various reasons, but they all boil down to that the first is just less readable and more prone to failure because a single line is doing more than one thing.

And all that for no real gain, and don't you tell me you find two lines of saved space is a real gain.

It's a similar thing to what happens when you have

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

Of course this example is much worse than yours.

寄居者 2024-07-13 04:54:35

在C/C++中,还存在一个问题,即用于指示指针类型的*仅适用于紧随其后的标识符。 因此,缺乏经验的开发人员的一个相当常见的错误是编写

int* var1, var2, var3;

并期望所有三个变量都是“int 指针”类型,而对于编译器来说,这读取为

int* var1;
int var2;
int var3;

仅使 var1 成为指针。

In C/C++, you also have the problem that the * used to indicate a pointer type only applies to the directly following identifier. So a rather common mistake of inexperienced developers is to write

int* var1, var2, var3;

and expecting all three variables to be of type 'int pointer', whereas for the compiler this reads as

int* var1;
int var2;
int var3;

making only var1 a pointer.

七颜 2024-07-13 04:54:35

通过单独的行,您可以在描述变量使用的每行上添加注释(如果从名称中不清楚)。

With separate lines, you have the opportunity to add a comment on each line describing the use of the variable (if it isn't clear from its name).

爱,才寂寞 2024-07-13 04:54:35

因为在某些语言中,示例中的 var2 和 var3 不是字符串,而是变体(无类型)。

Because in some languages, var2 and var3 in your example would not be strings, they would be variants (untyped).

皓月长歌 2024-07-13 04:54:35

为什么这是不好的做法? 我不认为是这样,只要你的代码仍然可读。

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

//better
int counter, 
    childCounter, 
    percentComplete;

Why is that bad practice? I don't think it is, as long as your code is still readable.

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

//better
int counter, 
    childCounter, 
    percentComplete;
薄荷→糖丶微凉 2024-07-13 04:54:35

诸如此类的情况又如何:

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

这也被认为是不好的做法吗? 我认为没关系,因为它反驳了之前提出的一些观点:

  • 它们肯定都是相同的类型(在我的静态类型 Java 世界中),
  • 则可以为每个添加注释
  • 如果您必须更改其中一个的类型, ,您可能必须为所有人做到这一点,并且所有四个都可以在一次更改中完成

所以在一个(尽管是臭代码)示例中,您有理由不这样做吗?

What about the case such as:

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

Is that considered bad practice as well? I would consider that okay as it counters some of the points previously made:

  • they would all definitely be the same type (in my statically typed Java-world)
  • comments can be added for each
  • if you have to change the type for one, you probably have to do it for all, and all four can be done in one change

So in an (albeit smelly code) example, is there reasons you wouldn't do that?

如何视而不见 2024-07-13 04:54:35

我的原因如下:

  • 可读性,如果您知道每一行只有一个,则更容易发现
  • 版本控制,行内更改更少,单行添加、更改或删除更多,更容易从一个分支合并到另一个分支

Here's my reasons:

  • Readability, easier to spot if you know there's only one on each line
  • Version control, less intra-line changes, more single-line additions, changes, or deletions, easier to merge from one branch to another
感受沵的脚步 2024-07-13 04:54:35

说实话我并不反对。 我认为将相似的变量分组在同一行上是完全可行的,例如

float fMin, fMax;

然而,当变量不相关时,我会避开,例如

int iBalance、iColor;

To be honest I am not against it. I think that its perfectly feasible to group similar variables on the same line e.g.

float fMin, fMax;

however I steer clear when the variables are unrelated e.g.

int iBalance, iColor;

陈甜 2024-07-13 04:54:35

关联。

仅仅因为两个变量是 String 类型并不意味着它们彼此密切相关。

如果两个(或多个)变量通过函数而不是变量类型密切相关,那么也许它们可以一起声明。 即,只有当程序的读者将两个变量放在一起有意义时,它们实际上才应该放在一起

Relevance.

Just because two variables are of type String does not mean they are closely related to each other.

If the two (or more) variables are closely related by function, rather then variable type, then maybe they could be declared together. i.e. only if it makes sense for a reader of your program to see the two variables together should they actually be placed together

草莓味的萝莉 2024-07-13 04:54:35

同意 edg 的观点,还因为将每个变量放在单独的行上更具可读性且易于维护。 您可以立即看到类型、范围和其他修饰符,并且当您更改修饰符时,它仅适用于您想要的变量 - 这可以避免错误。

Agree with edg, and also because it is more readable and easy for maintenance to have each variable on separate line. You immediately see the type, scope and other modifiers and when you change a modifier it applies only to the variable you want - that avoids errors.

噩梦成真你也成魔 2024-07-13 04:54:35

假设您需要使用多种语言进行编码,可能是 C、C#、VBA 等。

通过采取更保守的立场,即适当地拆分声明,

private String var1
private String var2
private String var3

您实际上采用了一种更通用的风格。 你会第一次就做对,至少在更多时候是这样。

此外,VBA 中的样式

private String var1, var2, var3

会隐式将 var2 和 var3 声明为 Variant。 该代码可以工作,因为 var2 和 var3 会默默地成为变体。 方便,但令人讨厌。

最后也是最不重要的一点是,拆分声明可以让您更自由地分配初始默认值。 更短的代码。

private String var1 = "plutonium";
private String var2 = "soft-shelled turtle";
private String var3 = "X5Jetstar";

或者在 VBA 中,就像

dim var1 as String: var1 = "plutonium"

我总是试图坚持良好的编码习惯,这种习惯会传播到其他语言中。

Suppose you need to code in several languages, maybe C, C#, VBA, etc.

By adopting a more conservative stance, that is, splitting the declaration appropriately,

private String var1
private String var2
private String var3

you're really adopting a style which is a bit more universal. You'll get it right the first time, at least more often.

Further, a style like

private String var1, var2, var3

in VBA would implicitly declare var2 and var3 as Variant. The code would work because var2 and var3 would be, silently, variants. Convenient, but nasty.

Last and certainly least, splitting the declarations gives you a bit more freedom to possibly assign intial default values. Shorter code.

private String var1 = "plutonium";
private String var2 = "soft-shelled turtle";
private String var3 = "X5Jetstar";

or in VBA, something like

dim var1 as String: var1 = "plutonium"

I would always try to stick with decent coding habits which would spread around other languages.

懷念過去 2024-07-13 04:54:35

当您可以并且想要初始化减速变量时,这通常是不好的做法。 这可能还不错的一个例子是:

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

It is bad practice mostly when you can and want to initialize variables on the deceleration. An example where this might not be so bad is:

string a,b;
if (Foo())
{
  a = "Something";
  b = "Something else";
}
else
{
  a = "Some other thing";
  b = "Out of examples";
}
夏の忆 2024-07-13 04:54:35
  1. 当您使用版本控制工具(由 Michel 介绍)时,对您来说更加明显
  2. 当您遇到最简单的溢出/下溢或编译错误并且您的眼睛无法指出明显的
  3. 反面情况(即多变量单行声明)优点较少(“代码文本垂直可见性”是单例)
  1. to be more apparent to you when using Version Control tools (covered by Michel)
  2. to be more readable to you when you have the simplest overflow/underflow or compile error and your eyes failed to point out the obvious
  3. to defend the opposite (i.e. multi-variable single-line declaration) has less pros ("code textual vertical visibility" being a singleton)
〃安静 2024-07-13 04:54:35

一般来说,出于其他人讨论的版本控制和注释原因,我会在 95% 的情况下应用它。 然而,在某些情况下它确实有意义,例如,如果我正在编码图形并且我想要几个变量来表示纹理坐标(按照惯例总是引用为 s 和 t),那么将它们声明为

int s, t; // 纹理坐标

恕我直言,通过缩短代码和明确这两个变量属于一起来增强代码的可读性(当然,有些人会主张在这种情况下使用单点类变量)。

Generally it is, for the version control and commenting reasons discussed by others, and I'd apply that in 95% of all cases. however there are circumstances where it does make sense, for example if I'm coding graphics and I want a couple of variables to represent texture coordinates (always referenced by convention as s and t) then the declaring them as

int s, t; // texture coordinates

IMHO enhances code readability both by shortening the code and by making it explicit that these two variables belong together (of course some would argue for using a single point class variable in this case).

青衫负雪 2024-07-13 04:54:35

在尝试这个问题时 https://www.interviewbit.com/problems/remove -element-from-array/

方法 1 给出了此代码超出的内存限制:

类型 1:

int i,j;

类型 2:

int i;
int j;

类型 1:给出超出内存限制

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;
}

而类型 2 工作得很好

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;
}

while attempting this question https://www.interviewbit.com/problems/remove-element-from-array/

Method 1 gives Memory Limit exceeded for this code:

Type 1:

int i,j;

Type 2:

int i;
int j;

type 1: Gives Memory Limit Exceeded

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;
}

Whereas type 2 works perfectly fine

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;
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文