顺便说一句,我认为这些的命名约定来自早期的 Fortran 语言,其中我是第一个整数变量(A - H 是浮点数)?
I tend to use i, j, k for very localized loops (only exist for a short period in terms of number of source lines). For variables that exist over a larger source area, I tend to use more detailed names so I can see what they're for without searching back in the code.
By the way, I think that the naming convention for these came from the early Fortran language where I was the first integer variable (A - H were floats)?
Depends on the context I suppose. If you where looping through a set of Objects in some collection then it should be fairly obvious from the context what you are doing.
for(int i = 0; i < 10; i++)
{
// i is well known here to be the index
objectCollection[i].SomeProperty = someValue;
}
However if it is not immediately clear from the context what it is you are doing, or if you are making modifications to the index you should use a variable name that is more indicative of the usage.
for (int i = 0; i < 10; i++)
{
for (int j = 0; j < 10; j++)
{
string s = datarow[i][j].ToString(); // or worse
}
}
对于程序员来说,不经意地交换代码中的 i 和 j 是很常见的,尤其是当他们视力不好或者他们的 Windows 主题是“hotdog”时。 对我来说,这始终是一种“代码味道”——如果没有搞砸的话,这种情况很少见。
i is fine, but something like this is not:
for (int i = 0; i < 10; i++)
{
for (int j = 0; j < 10; j++)
{
string s = datarow[i][j].ToString(); // or worse
}
}
Very common for programmers to inadvertently swap the i and the j in the code, especially if they have bad eyesight or their Windows theme is "hotdog". This is always a "code smell" for me - it's kind of rare when this doesn't get screwed up.
当然,i 是可以接受的。 然而,一个学期我从一位 C++ 老师那里学到了很多东西,他拒绝使用没有每个变量的描述性名称的代码。 描述性地命名所有内容的简单行为迫使我更加努力地思考我的代码,并且在该课程之后我编写了更好的程序,不是通过学习 C++,而是通过学习命名所有内容。 Code Complete 对于同一主题有一些好话。
i is acceptable, for certain. However, I learned a tremendous amount one semester from a C++ teacher I had who refused code that did not have a descriptive name for every single variable. The simple act of naming everything descriptively forced me to think harder about my code, and I wrote better programs after that course, not from learning C++, but from learning to name everything. Code Complete has some good words on this same topic.
使用 i 代替更具体的变量名有什么价值? 节省 1 秒或 10 秒,甚至 30 秒的思考和打字时间?
使用 i 的成本是多少? 也许什么也没有。 也许代码很简单,使用 i 就可以了。 但也许,也许,使用 i 会迫使将来接触这段代码的开发人员不得不思考一下“我在这里的意思是什么?” 他们必须思考:“它是一个索引、一个计数、一个偏移量还是一个标志?” 他们必须思考:“这个改变安全吗?正确吗?我会落后 1 分吗?”
在编写代码时使用 i 可以节省时间和智力工作,但最终可能会在将来花费更多的智力工作,甚至可能导致由于误解代码而无意中引入缺陷。
What is the value of using i instead of a more specific variable name? To save 1 second or 10 seconds or maybe, maybe, even 30 seconds of thinking and typing?
What is the cost of using i? Maybe nothing. Maybe the code is so simple that using i is fine. But maybe, maybe, using i will force developers who come to this code in the future to have to think for a moment "what does i mean here?" They will have to think: "is it an index, a count, an offset, a flag?" They will have to think: "is this change safe, is it correct, will I be off by 1?"
Using i saves time and intellectual effort when writing code but may end up costing more intellectual effort in the future, or perhaps even result in the inadvertent introduction of defects due to misunderstanding the code.
Generally speaking, most software development is maintenance and extension, so the amount of time spent reading your code will vastly exceed the amount of time spent writing it.
It's very easy to develop the habit of using meaningful names everywhere, and once you have that habit it takes only a few seconds more to write code with meaningful names, but then you have code which is easier to read, easier to understand, and more obviously correct.
i is definitely acceptable. Not sure what kind of justification I need to make -- but I do use it all of the time, and other very respected programmers do as well.
i 不一定必须增量只要增量一致且清晰,当然可能会在 iterand 结束之前停止,但如果它改变了方向,或者没有被循环的迭代修改(包括对 iterator.insertAfter( 的邪恶使用),则为 1 )在正向循环中),我尝试记住使用不同的东西。 这表明“这不仅仅是一个简单的循环变量,因此这可能不是一个简单的循环”。
I use i for short loops.
The reason it's OK is that I find it utterly implausible that someone could see a declaration of iterator type, with initializer, and then three lines later claim that it's not clear what the variable represents. They're just pretending, because they've decided that "meaningful variable names" must mean "long variable names".
The reason I actually do it, is that I find that using something unrelated to the specific task at hand, and that I would only ever use in a small scope, saves me worrying that I might use a name that's misleading, or ambiguous, or will some day be useful for something else in the larger scope. The reason it's "i" rather than "q" or "count" is just convention borrowed from mathematics.
I don't use i if:
The loop body is not small, or
the iterator does anything other than advance (or retreat) from the start of a range to the finish of the loop:
i doesn't necessarily have to go in increments of 1 so long as the increment is consistent and clear, and of course might stop before the end of the iterand, but if it ever changes direction, or is unmodified by an iteration of the loop (including the devilish use of iterator.insertAfter() in a forward loop), I try to remember to use something different. This signals "this is not just a trivial loop variable, hence this may not be a trivial loop".
我认为 i 在 for 循环情况下是完全可以接受的。 我一直发现这是相当标准的,并且当我在这种情况下使用时从未真正遇到解释问题。 foreach 循环变得有点棘手,我认为这实际上取决于您的情况。 我很少在 foreach 中使用 i ,只在 for 循环中使用,因为我发现 i 在这些情况下太缺乏描述性。 对于 foreach 我尝试使用正在循环的对象类型的缩写。 例如:
foreach(DataRow dr in datatable.Rows)
{
//do stuff to/with datarow dr here
}
无论如何,只要我的 0.02 美元。
i think i is completely acceptable in for-loop situations. i have always found this to be pretty standard and never really run into interpretation issues when i is used in this instance. foreach-loops get a little trickier and i think really depends on your situation. i rarely if ever use i in foreach, only in for loops, as i find i to be too un-descriptive in these cases. for foreach i try to use an abbreviation of the object type being looped. e.g:
foreach(DataRow dr in datatable.Rows)
{
//do stuff to/with datarow dr here
}
i 被广泛称为循环迭代器,因此,如果您在循环之外使用它,那么实际上更有可能让维护程序员感到困惑,但如果您使用更具描述性的内容(例如 filecounter< /code>),它使代码变得更好。
As long as you're using it temporarily inside a simple loop and it's obvious what you're doing, sure. That said, is there no other short word you can use instead?
i is widely known as a loop iterator, so you're actually more likely to confuse maintenance programmers if you use it outside of a loop, but if you use something more descriptive (like filecounter), it makes code nicer.
For the crowd that says "i is understood as an iterator", that may be true, but to me that is the equivalent of comments like 'Assign the value 5 to variable Y. Variable names like comment should explain the why/what not the how.
To use an example from a previous answer:
for(int i = 0; i < 10; i++)
{
// i is well known here to be the index
objectCollection[i].SomeProperty = someValue;
}
Is it that much harder to just use a meaningful name like so?
但是,如果您执行任意循环,则 i 是可以接受的。 正如一位同事向我描述的那样 - i 是一种约定,意味着“此变量只能由 for 循环结构修改。如果情况不是这样,请不要这样做使用i”
It depends. If you're iterating over some particular set of data then I think it makes more sense to use a descriptive name. (eg. filecounter as Dan suggested).
However, if you're performing an arbitrary loop then i is acceptable. As one work mate described it to me - i is a convention that means "this variable is only ever modified by the for loop construct. If that's not true, don't use i"
The use of i, j, k for INTEGER loop counters goes back to the early days of FORTRAN. Personally I don't have a problem with them so long as they are INTEGER counts. But then I grew up on FORTRAN!
// recommended style ● // "typical" single-letter style
●
for (ii=0; ii<10; ++ii) { ● for (i=0; i<10; ++i) {
for (jj=0; jj<10; ++jj) { ● for (j=0; j<10; ++j) {
mm[ii][jj] = ii * jj; ● m[i][j] = i * j;
} ● }
} ● }
in case the benefit isn't immediately obvious: searching through code for any single letter will find many things that aren't what you're looking for. the letter i occurs quite often in code where it isn't the variable you're looking for.
我这样做已经至少10年了。
请注意,很多人评论说上述任何一个/两个都是“丑陋的”......
my feeling is that the concept of using a single letter is fine for "simple" loops, however, i learned to use double-letters a long time ago and it has worked out great.
// recommended style ● // "typical" single-letter style
●
for (ii=0; ii<10; ++ii) { ● for (i=0; i<10; ++i) {
for (jj=0; jj<10; ++jj) { ● for (j=0; j<10; ++j) {
mm[ii][jj] = ii * jj; ● m[i][j] = i * j;
} ● }
} ● }
in case the benefit isn't immediately obvious: searching through code for any single letter will find many things that aren't what you're looking for. the letter i occurs quite often in code where it isn't the variable you're looking for.
i've been doing it this way for at least 10 years.
note that plenty of people commented that either/both of the above are "ugly"...
发布评论
评论(21)
这是另一个完全没问题的例子:
Here's another example of something that's perfectly okay:
我倾向于将 i、j、k 用于非常局部的循环(就源代码行数而言仅存在很短的一段时间)。 对于存在于较大源区域的变量,我倾向于使用更详细的名称,这样我就可以看到它们的用途,而无需在代码中搜索。
顺便说一句,我认为这些的命名约定来自早期的 Fortran 语言,其中我是第一个整数变量(A - H 是浮点数)?
I tend to use i, j, k for very localized loops (only exist for a short period in terms of number of source lines). For variables that exist over a larger source area, I tend to use more detailed names so I can see what they're for without searching back in the code.
By the way, I think that the naming convention for these came from the early Fortran language where I was the first integer variable (A - H were floats)?
我认为取决于上下文。 如果您在某些地方循环访问一组对象
那么从上下文中你正在做什么应该是相当明显的。
但是,如果从上下文中无法立即清楚您正在做什么,或者您正在对索引进行修改,则应该使用更能指示用法的变量名称。
Depends on the context I suppose. If you where looping through a set of Objects in some
collection then it should be fairly obvious from the context what you are doing.
However if it is not immediately clear from the context what it is you are doing, or if you are making modifications to the index you should use a variable name that is more indicative of the usage.
对于程序员来说,“i”意味着“循环计数器”。 没有什么问题。
"i" means "loop counter" to a programmer. There's nothing wrong with it.
i 没问题,但类似这样的事情就不行了:
对于程序员来说,不经意地交换代码中的 i 和 j 是很常见的,尤其是当他们视力不好或者他们的 Windows 主题是“hotdog”时。 对我来说,这始终是一种“代码味道”——如果没有搞砸的话,这种情况很少见。
i is fine, but something like this is not:
Very common for programmers to inadvertently swap the i and the j in the code, especially if they have bad eyesight or their Windows theme is "hotdog". This is always a "code smell" for me - it's kind of rare when this doesn't get screwed up.
当然,
i
是可以接受的。 然而,一个学期我从一位 C++ 老师那里学到了很多东西,他拒绝使用没有每个变量的描述性名称的代码。 描述性地命名所有内容的简单行为迫使我更加努力地思考我的代码,并且在该课程之后我编写了更好的程序,不是通过学习 C++,而是通过学习命名所有内容。 Code Complete 对于同一主题有一些好话。i
is acceptable, for certain. However, I learned a tremendous amount one semester from a C++ teacher I had who refused code that did not have a descriptive name for every single variable. The simple act of naming everything descriptively forced me to think harder about my code, and I wrote better programs after that course, not from learning C++, but from learning to name everything. Code Complete has some good words on this same topic.i 非常常见,即使对于喜欢描述性变量名的人来说也是可以接受的。
绝对不可接受的(在我的书中也是一个罪过)是在任何其他上下文中使用 i、j 或 k,而不是作为循环中的整数索引......例如
i is so common that it is acceptable, even for people that love descriptive variable names.
What is absolutely unacceptable (and a sin in my book) is using i,j, or k in any other context than as an integer index in a loop.... e.g.
使用 i 代替更具体的变量名有什么价值? 节省 1 秒或 10 秒,甚至 30 秒的思考和打字时间?
使用 i 的成本是多少? 也许什么也没有。 也许代码很简单,使用 i 就可以了。 但也许,也许,使用 i 会迫使将来接触这段代码的开发人员不得不思考一下“我在这里的意思是什么?” 他们必须思考:“它是一个索引、一个计数、一个偏移量还是一个标志?” 他们必须思考:“这个改变安全吗?正确吗?我会落后 1 分吗?”
在编写代码时使用 i 可以节省时间和智力工作,但最终可能会在将来花费更多的智力工作,甚至可能导致由于误解代码而无意中引入缺陷。
一般来说,大多数软件开发都是维护和扩展,因此阅读代码所花费的时间将大大超过编写代码所花费的时间。
养成在任何地方使用有意义的名称的习惯是很容易的,一旦你养成了这种习惯,用有意义的名称编写代码只需要多花几秒钟,但是你的代码会更容易阅读、更容易理解等等。显然是正确的。
What is the value of using i instead of a more specific variable name? To save 1 second or 10 seconds or maybe, maybe, even 30 seconds of thinking and typing?
What is the cost of using i? Maybe nothing. Maybe the code is so simple that using i is fine. But maybe, maybe, using i will force developers who come to this code in the future to have to think for a moment "what does i mean here?" They will have to think: "is it an index, a count, an offset, a flag?" They will have to think: "is this change safe, is it correct, will I be off by 1?"
Using i saves time and intellectual effort when writing code but may end up costing more intellectual effort in the future, or perhaps even result in the inadvertent introduction of defects due to misunderstanding the code.
Generally speaking, most software development is maintenance and extension, so the amount of time spent reading your code will vastly exceed the amount of time spent writing it.
It's very easy to develop the habit of using meaningful names everywhere, and once you have that habit it takes only a few seconds more to write code with meaningful names, but then you have code which is easier to read, easier to understand, and more obviously correct.
是的,事实上它是首选,因为任何阅读你的代码的程序员都会明白它只是一个迭代器。
Yes, in fact it's preferred since any programmer reading your code will understand that it's simply an iterator.
我绝对可以接受。 不确定我需要做出什么样的理由——但我确实一直在使用它,其他非常受人尊敬的程序员也这样做。
我想,社会认可:)
i is definitely acceptable. Not sure what kind of justification I need to make -- but I do use it all of the time, and other very respected programmers do as well.
Social validation, I guess :)
我使用 i 来进行短循环。
之所以没问题,是因为我发现完全难以置信的是,有人可以看到带有初始值设定项的迭代器类型的声明,然后三行后声称不清楚该变量代表什么。 他们只是假装,因为他们认为“有意义的变量名”必须意味着“长变量名”。
我实际上这样做的原因是,我发现使用与手头的特定任务无关的东西,并且我只会在小范围内使用,这样我就不用担心我可能会使用误导性的、模棱两可的名称,或者有一天会对更大范围内的其他事情有用。 之所以是“i”而不是“q”或“count”,只是借用了数学的惯例。
我不使用 i 如果:
i 不一定必须增量只要增量一致且清晰,当然可能会在 iterand 结束之前停止,但如果它改变了方向,或者没有被循环的迭代修改(包括对 iterator.insertAfter( 的邪恶使用),则为 1 )在正向循环中),我尝试记住使用不同的东西。 这表明“这不仅仅是一个简单的循环变量,因此这可能不是一个简单的循环”。
I use i for short loops.
The reason it's OK is that I find it utterly implausible that someone could see a declaration of iterator type, with initializer, and then three lines later claim that it's not clear what the variable represents. They're just pretending, because they've decided that "meaningful variable names" must mean "long variable names".
The reason I actually do it, is that I find that using something unrelated to the specific task at hand, and that I would only ever use in a small scope, saves me worrying that I might use a name that's misleading, or ambiguous, or will some day be useful for something else in the larger scope. The reason it's "i" rather than "q" or "count" is just convention borrowed from mathematics.
I don't use i if:
i doesn't necessarily have to go in increments of 1 so long as the increment is consistent and clear, and of course might stop before the end of the iterand, but if it ever changes direction, or is unmodified by an iteration of the loop (including the devilish use of iterator.insertAfter() in a forward loop), I try to remember to use something different. This signals "this is not just a trivial loop variable, hence this may not be a trivial loop".
如果您将其命名为描述其循环内容的名称,则会有所帮助。 但我通常只使用 i。
It helps if you name it something that describes what it is looping through. But I usually just use i.
如果“更语义化的东西”是“迭代器”,那么没有理由不使用 i; 这是一个很好理解的习语。
If the "something more semantic" is "iterator" then there is no reason not to use i; it is a well understood idiom.
我认为 i 在 for 循环情况下是完全可以接受的。 我一直发现这是相当标准的,并且当我在这种情况下使用时从未真正遇到解释问题。 foreach 循环变得有点棘手,我认为这实际上取决于您的情况。 我很少在 foreach 中使用 i ,只在 for 循环中使用,因为我发现 i 在这些情况下太缺乏描述性。 对于 foreach 我尝试使用正在循环的对象类型的缩写。 例如:
无论如何,只要我的 0.02 美元。
i think i is completely acceptable in for-loop situations. i have always found this to be pretty standard and never really run into interpretation issues when i is used in this instance. foreach-loops get a little trickier and i think really depends on your situation. i rarely if ever use i in foreach, only in for loops, as i find i to be too un-descriptive in these cases. for foreach i try to use an abbreviation of the object type being looped. e.g:
anyways, just my $0.02.
只要您在一个简单的循环中临时使用它,并且您在做什么就很明显,当然。 也就是说,没有其他简短的词可以代替吗?
i
被广泛称为循环迭代器,因此,如果您在循环之外使用它,那么实际上更有可能让维护程序员感到困惑,但如果您使用更具描述性的内容(例如filecounter< /code>),它使代码变得更好。
As long as you're using it temporarily inside a simple loop and it's obvious what you're doing, sure. That said, is there no other short word you can use instead?
i
is widely known as a loop iterator, so you're actually more likely to confuse maintenance programmers if you use it outside of a loop, but if you use something more descriptive (likefilecounter
), it makes code nicer.我应该指出 i 和 j 也是矩阵索引的数学符号。 通常,您会循环遍历数组。 所以这是有道理的。
I should point out that i and j are also mathematical notation for matrix indices. And usually, you're looping over an array. So it makes sense.
只要您使用 i 来计数循环,或者使用从 0(或 1,取决于 PL)到 n 的索引的一部分,那么我会说 i 没问题。
否则,它可能很容易命名为有意义的东西,它不仅仅是一个索引。
As long as you are either using i to count loops, or part of an index that goes from 0 (or 1 depending on PL) to n, then I would say i is fine.
Otherwise its probably easy to name i something meaningful it its more than just an index.
我要反其道而行之说“不”。
对于那些说“i 被理解为迭代器”的人来说,这可能是真的,但对我来说,这相当于“将值 5 分配给变量 Y”之类的注释。像注释这样的变量名称应该解释为什么/什么不是如何。
借用之前答案中的一个例子:
使用这样一个有意义的名称是不是更难?
诚然,(借用的)变量名 objectCollection 的命名也相当糟糕。
I am going to go against the grain and say no.
For the crowd that says "i is understood as an iterator", that may be true, but to me that is the equivalent of comments like 'Assign the value 5 to variable Y. Variable names like comment should explain the why/what not the how.
To use an example from a previous answer:
Is it that much harder to just use a meaningful name like so?
Granted the (borrowed) variable name objectCollection is pretty badly named too.
这取决于。
如果您要迭代某些特定的数据集,那么我认为使用描述性名称更有意义。 (例如,丹建议的
filecounter
)。但是,如果您执行任意循环,则
i
是可以接受的。 正如一位同事向我描述的那样 -i
是一种约定,意味着“此变量只能由for
循环结构修改。如果情况不是这样,请不要这样做使用i
”It depends.
If you're iterating over some particular set of data then I think it makes more sense to use a descriptive name. (eg.
filecounter
as Dan suggested).However, if you're performing an arbitrary loop then
i
is acceptable. As one work mate described it to me -i
is a convention that means "this variable is only ever modified by thefor
loop construct. If that's not true, don't usei
"i、j、k 用于 INTEGER 循环计数器的使用可以追溯到 FORTRAN 的早期。
就我个人而言,只要它们是整数计数,我对它们就没有问题。
但后来我是在 FORTRAN 环境下长大的!
The use of i, j, k for INTEGER loop counters goes back to the early days of FORTRAN.
Personally I don't have a problem with them so long as they are INTEGER counts.
But then I grew up on FORTRAN!
我的感觉是,使用单个字母的概念对于“简单”循环来说很好,但是,我很久以前就学会了使用双字母,而且效果很好。
我上周问了一个类似的问题,以下是我自己的回答:
in case the benefit isn't immediately obvious: searching through code for any single letter will find many things that aren't what you're looking for. the letter
i
occurs quite often in code where it isn't the variable you're looking for.我这样做已经至少10年了。
请注意,很多人评论说上述任何一个/两个都是“丑陋的”......
my feeling is that the concept of using a single letter is fine for "simple" loops, however, i learned to use double-letters a long time ago and it has worked out great.
i asked a similar question last week and the following is part of my own answer:
in case the benefit isn't immediately obvious: searching through code for any single letter will find many things that aren't what you're looking for. the letter
i
occurs quite often in code where it isn't the variable you're looking for.i've been doing it this way for at least 10 years.
note that plenty of people commented that either/both of the above are "ugly"...