Yes, it is not safe to rely on indices.
In your first example you completely rely on that the indices of contact_id
and contact_name
matches.
So say you would extract the contact_id
and contact_name
for a single index to get the user like this:
var User = { "Id": contact_id[0], "Name": contact_name[0] };
Log.print(User);
>> 455 Administrator
This may be fine and dandy for now, but imagine what will happen when an element is introduced in the wrong index? Say a new developer comes along and decides to insert a new user but s/he is not too careful about where he's introducing or he misinterprets how the JSON should be formatted it and the result is a JSON looking like
{
"contact_id": [
"455",
"456",
"464"
],
"contact_name": [
"Administrator",
"Main contact",
"Sub Contact"
]
}
Here the new developer thought that the contact_id
might just be ordered descendingly , and that contact_name
should also be ordered descendingly but by its roles (because, once again, s/he misinterprets contact_name
to be a list of roles even though the array is named contact_name
).
As such he has introduced the new user's id at index 1 and the new user's name at index 2 and suddenly you are left debugging why all of your user's name, id, etc is wrong.
So why is it wrong?
Because you should never trust that either yourself in the future, or someone else will adhere to your arbitrary rules that any given index over all of your arrays are associated.
This is also the reason for why you should not match e.g a role permission on indices solely. Say you got an ordered list of roles
var roles = [
"Admin",
"LocalAdmin",
"ContentManager",
"User"
];
And in your permission script you check for user.role == roles[0]
, and sometimes in the future - who is unaware that the permission check that you wrote works like that - decides to add a new user "SuperAdmin"
, creating the following JSON
var roles = [
"SuperAdmin",
"Admin",
"LocalAdmin",
"ContentManager",
"User"
];
By the logic of matches by indices user.role == roles[0]
, every admin has now become an SuperAdmin even though they shouldn't.