short index vs. int index

[ardavirus]

Hello again,
In every book or tutorial about C language I happened to take a look, they use indexes for loops and arrays, in programs used as examples, that won't count/index but a very small number, like that:

.
.
#define MAX_LENGTH 10

int index;
int array[MAX_LENGTH];

for (index = 0; index < MAX_LENGTH; ++index)
  array[index] = 0;
.
.

I have written the same examples with a minor change and they seem to compile and run fine.

.
.
#define MAX_LENGTH 10

short index;
int array[MAX_LENGTH];

for (index = 0; index < MAX_LENGTH; ++index)
  array[index] = 0;
.
.

Isn't it better idea and a good practice to use a short index instead of an int since we are going to deal with very small values?

If not why ?

Thank you for your time to help me!

[CommonTater]

Either way is fine...

The common argument is that an int is *supposed* to be the native size of the registers in the target processor (hense the business about 16 vs 32 vs 64 bit compilers) and *may* offer a slight performance advantage over short or char for loop counters and iterators by eliminating the need to convert when loading the values. However; most decent compilers keep loop counters in registers after the initial read from memory, so that is no longer much of an issue.

[Salem]

If you're on a machine that lacks easy byte / word / long access to registers (like say the x86), you might be causing more work to keep the value within bounds of the shorter data type.

Do you ever have loops which run for more iterations than can be fit into a short?
Or more insidiously, where your #define limit can change after you've written the code to be >short, you're basically introducing bug opportunities.

Picking a single style which works all the time is preferable to trying to second-guess (and getting it wrong) what the future is likely to be.

[ardavirus]

@CommonTater & Salem
Thank you so much for your quick and precise answer.