In Fortran, variables beginning with the letters i through n have integer type by default, whereas all other letters imply a real-number (floating-point) variable. You can change this by declaring a type, but using i for a real is non-obvious.
(Hence the old joke, "God is real — unless declared integer.")
idk, this arbitrary i-n range behaving differently than other variables sounds like a terrible source of weird bugs to me. I don't think variable names should ever change a program's behavior.
edit:
Many old Fortran 77 programs uses these implicit rules, but you should not! The probability of errors in your program grows dramatically if you do not consistently declare your variables.
This comes from early years, when FORTRAN was introduced and the programmers needed to save space in the punch cards. Today, to avoid this possible source of bugs, you usually state "implicit none" in the preamble.
in programming, and in mathematics, it's always been weird to me that frequently paired variables are basically the most easily confused for one another pairs, especially when written quickly or sloppily.
When travelling in places where Latin script is not official (e.g. Middle East, Asia), I notice many mix-ups of pq and b. I always wondered how this would impact their ability to learn to program.
I always like to joke in coding interviews that I really like to make variable names as long as I can so they are very precisely named. Then when I get to a double nested loop I hit them with iterator and jiterator instead of I and j
Even for indexes I do index or something more specific for what it's indexing. Any simple iteration I just do map or each so the only time I ever need to actually index things is for more complex scenarios in which case it's worth it to have better names. Also with modem IDEs, auto complete is really good so you don't need to write a full variable name more than once.
that's good too. I recommended k over j if using single letters, but I actually tend to use idx when using indices, and more descriptive idx_this, idx_that for rare index-based nested loops.
When I was a baby coder back in the 90s we were taught that these names were meant to save space in the symbol table because at one time space was so limited that naming your variable n rather than numElementsInArray would have an impact
i for index or iteration. Using j, k, l... in loops signals (imho) that there is most likely an outer loop and the one using j, k, l are nested. x and y of course are carthesian coordinates . n is used as amount of substance in SI-unit-system, m is mass, maybe thats why it is used as amount of items in a set (Menge).
Programming computers have started to solve mathematical problems and math already used these symbols for centuries(?), so why you should change them? They are well established even in simple school mathematics. And at the end of the day a computer is nothing more than a calculator.
Readability and maintainability, mostly. They are one character long mostly to help handwriting compact formulas, but their pros end there. For software, though:
"Programs are meant to be read by humans and only incidentally for computers to execute"
For readability the loop has to be short, so it is not really a problem, and it is also clear the iterated variable.
Long loops where the iterated variable is called far from the loop are anyway very bad for readability. There is a much worse problem in that code than i and j
Usually variables like that can be avoided with itterators nowadays. If they can’t I like to use idx, if they are nested I name them after what they index, like idx_rows, idx_cols.
Ask the mathematicians, they started it. And I don't question their wisdom because a) maths can be very scary and b) I like Arch almost as much as being dominated