|
I always use index and sometimes preppend it with the object or value i am indexing. It leads to a bit more verbose code but it is a hell of a lot easier to understand. Just my opinion.
|
|
|
|
|
Yes, it started in FORTRAN and leads to the following joke:
God is real unless declared integer
At least now you have the context so you can see the humor 
|
|
|
|
|
Sorry, I still don't see the humour!
(Sound of tumbleweed blowing)
|
|
|
|
|
Since I, j, k, l are int by default, a variable named God would, by default, be a 'real' number - ie, floating point. You'd have to declare the variable God to be an integer in order for it to be taken that way.
Yes, this is probably a good candidate for the most delayed response ever.
|
|
|
|
|
mc42 wrote: Yes, this is probably a good candidate for the most delayed response ever.
It did take me a while to get the context there. Thanks for explaining.
It does tickle me that an Imaginary being defaults to Real, while i is definitely not imaginary. Mathematicians would shudder.
(Edited for grammar)
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
In my mind, it was because of FORTRAN. Back in the day, we didn't have all that many languages to choose from and most of us wrote in 360 assembler, FORTRAN, or COBOL. As others have said, while FORTRAN did have typing, variables starting with i-n were defaulted to integers so we just used i - followed by j, k, l in nested loops - for simplicity.
We also used foo, foobar, and jane for "temp" variables. foo and foobar were common for IBM programmers and jane was common in DEC code.
|
|
|
|
|
I've never used fortran, I always thought of 'i' as an unnamed integer. A throw-away variable.
|
|
|
|
|
now that you made me think of it, I realized of my habit of using "t" instead of "i" as my favorite looping variable. It's because I learned of FOR loops back in 1984 when typing BASIC programs on my Commodore VIC20. The user manual had several sound-effects example listings, mostly composed of a FOR T=something statement, where T stayed (I guess) for time. I typed many of them and eventually got the habit of the "t" variable.
Effects were something like this:
10 REM LUNAR LANDING EFFECT
15 POKE 36878,15
20 FOR T=200 TO 120 STEP -1
30 POKE 36876,T
40 FOR I=1 TO 100:NEXT I
50 NEXT T
(for the curious ones, 368678 was for volume "up" and 36876 for playing tone).
|
|
|
|
|
I use i because I was taught so in school, also every example in any book use i (j, k, etc.) as loop variables so I assume it seems natural to me. By the way I always thought i stood for index.
|
|
|
|
|
Yes, as others have said for many it was a carryover from FORTRAN. Nothing formal that I know of, just using i in FORTRAN and then out of habit using it in 'C' as programmers moved over to that and other newer languages.
|
|
|
|
|
When I first learned about mathematical functions f(x)(a dozen years before my first programming class) I was told mathematicians used "i" for the first incrementing variable, "j" for the next and so on.
When I started to learn programming languages, a FORTRAN professor (FORTRAN as in "FORmula TRANslation") who (of course) was a member of the Math department, said something along the lines of "This is not the theology department but using anything other that "I" for the first incremental etc is heresy. Those who want to use 'meaningful words' should consider being English or Philosophy majors and take Professor So-and-So's COBOL class."
So, 'I' as an index did not start with FORTRAN, it started before FORTRAN, but it fit nicely because those who used FORTRAN knew its meaning from math studies.
|
|
|
|
|
Yes, it is so: i, j and k are standard notation for mathematical arithmetic progressions and series.
From well before FORTRAN. But FORTRAN was designed by mathematicians, so we programmers are carrying over the notation.
a,b,c -> constants
x,y,z -> unknown terms (or real coordinates in cartesian plane)
k,j,i -> INTEGER indexes or vector coordinates.
I think Gauss was already using this conventions, more than 100 years ago.
Gauss wins. As always.
|
|
|
|
|
|
Fortran probably got it from math.
Now math... I don't know.
|
|
|
|
|
I've always used 'x'.
Why? Because a "Programming in C" book I started with used it.
So I just got used to it I guess.
|
|
|
|
|
It was also a feature of some early BASIC implementations. There were 26 variables available; A through H were floating point, I through P (??) were integers; R(??) through Z were also floating point. The only explicit type declarations were to suffix one of the single-letter variables with the $ symbol to indicate string. "I" was commonly used for loop control as being the first integer variable. It's a habit I learned in the 1960s and I still use it (very occasionally). Old habits die hard...
|
|
|
|
|
while(life!=death)
{
age++;
research++;
development++;
}
|
|
|
|
|
Hi,
Others have said this, but it deserves to be repeated:
This is classical math (handwritten, typed or printed), from a couple of centuries before the advent of computers. It's pretty natural that it was adopted by most mathematically-oriented computer languages (and, consequently, by later languages), and it also explains why it feels natural to most programmers (who have read any math - which should be a reasonable expectation) even today.
indices: i, j, k (don't remember how it goes on after that
quantities: n, m (then p, q if I remember correctly - o can be confusing).
dimensions: x, y, z, t, (xi), (eta), (theta).
I don't remember what happens when we run out of letters for indices and quantities, but if I remember correctly these sequences also continue with greek letters.
So:
for (i = 0; i < n; i++)
{
for (j = 0; j < m; i++)
{
for (k = 0; k < p; k++)
{
}
}
}
Pretty straightforward. And Newton would have understood it without thinking... 
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
I personally use x (and y and z for nested loops - if you nest more than two levels, you need to redesign), I make it unsigned (unless there's a specific reason to use signed) because that more accurately models the real world, and I use the prefix form of the increment operator because it's potentially more efficient. So my canonical form of that construct would be:
for (unsigned x = 0; x < size; ++x)
And yes, some of my co-workers make fun of me. The ones who spend twice as much time debugging their code as I do debugging mine.
|
|
|
|
|
I use
for (int r = 0; r < size; i++)
because
1) "r" is directly next to "t" when I type "int[spaceBar]r", typing flow is much nicer;
2) "r" is on my left-hand vs. the right-hand, so when I type "someArray[r]" I type faster as my fingers type in sync with one another; seriously, try it for a week and you'll see it flows much better;
3) "r" means "repeat" (or "record") in my brain
4) using i reminds me of when I flunked Spanish... example: iFlunked!
5) I got sick of iThisCrap, iThatCrap, iWTF;
.... - even though I actually originated using "i[SomeWord]" during my Apple dayz ... yes, iCreatedThisMess
... r u kidding me? no, i am not!
|
|
|
|
|
I was looking at one old SQL stored proc and found this strange behaviour.
DECLARE @Scrap_Qty int
DECLARE @FilledQty int
SET @Scrap_Qty=10
SET @FilledQty = 2
BEGIN
IF @Scrap_Qty > @FilledQty
declare @currDate varchar(10)
Set @currDate= Convert(VARCHAR(10),GetDate(),103)
PRINT @currDate
END
Look at the if condition .. it does not have BEGIN..END... To make thing interesting weather if condition is true or false you will get the output for parameter @currDate
If I add PRINT @Scrap_Qty right after IF and run it again it will only print value for @Scrap_Qty if condition is true. Which leads to question why sql is not complaining about undeclared variable if @Scrap_Qty is less than @FilledQty ?
I would have assumed if condition without BEGIN .. END block will behave like a normal one line to execute if condition is true which in above block is declaration of @currDate variable.
DECLARE @Scrap_Qty int
DECLARE @FilledQty int
SET @Scrap_Qty=10
SET @FilledQty = 2
BEGIN
IF @Scrap_Qty > @FilledQty
PRINT @Scrap_Qty
declare @currDate varchar(10)
Set @currDate= Convert(VARCHAR(10),GetDate(),103)
PRINT @currDate
END
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
declare is not an 'executable' statement.
This means thet the if in your code relates to the set @currdate.... statement only.
Personally, I always use BEGIN...END, even for one liners, but that's a matter of individual preference.
Anyway, thanks for sharing.
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: Personally, I always use BEGIN...END, even for one liners, but
that's a matter of individual preference.
This is exactly the reason for it not to be individual preference. Enhances readability and maintenance. Also, if the original developer used Pablo's notion, they would very likely have encapsulated this right.
|
|
|
|
|
Pablo Aliskevicius wrote: if in your code relates to the set @currdate.... statement only
In that Case if @ScrapQty<@FilledQty it should not Print Date( as i Understood... If i Understood wrong pls clarify ).... But it's Displaying Date  .... Can You Explain That... Pls... Any Explanation will be appreciated....
Thanks....
|
|
|
|
|
The set statement is conditional (first one after the if).
The print statement is another, different statement, and not conditional; it will be executed always.
The point is: always write begin and end.
Best wishes,
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
