named fields vs compactness [closed]

Question

Are their any objective guiding priciples to choose between named fields over compactness?

const replacements = [
  { from: 'apple',  to: 'manzana' },
  { from: 'banana', to: 'plátano'  },
];

function replace(str, replacements) {
  for (const {from, to} of replacements) {
    str = str.replace(from, to);
  }
  return str;
}

vs

const replacements = [
  [ 'apple', 'manzana' ],
  [ 'banana', 'plátano' ],
];

function replace(str, replacements) {
  for (rep of replacements) {
    str = str.replace(...rep);
  }
  return str;
}

I think I prefer the first example. It feels documented to me and clearer. The second example is not clear to me, especially if the input data is separated from the function. I mean if I just see it in some library as in

const newStr = replace(str, [
  [ 'apple', 'manzana' ],
  [ 'banana', 'plátano' ],
]);

seems far less clear than

const newStr = replace(str, [
  { from: 'apple',  to: 'manzana' },
  { from: 'banana', to: 'plátano'  },
]);

Is there any principle to decide which or is it just entirely personal preference?

Sometimes there are criteria. For exmaple if the data is 100000 entries large maybe compactness outweighs any other criteria. In fact in that case you could argue for a single dimentional array to get even more compact (and even less clear)

const newStr = replace(str, [
  'apple', 'manzana',
  'banana', 'plátano',
]);

which is only slightly less incomprehensible than

const newStr = replace(str, ['apple', 'manzana', 'banana', 'plátano']);

But short of memory issues are there any other criteria for which to judge which style to use? There are a lot of occasions where using the spread operator suggests compactness but seems to make the code cryptic.

Answer 1

Is there any principle to decide which or is it just entirely personal preference?

There is no general principle that governs the use of language constructs, especially if both forms are supported by your language. Nevertheless, there are some common sense principles.

The first guiding principle here is readability and self-documentation. But here some comments can help to make both forms understandable.

A second principle is maintainability. What if in future you’d add another element to your data structure, such as the starting position ? Anonymous data structures, where the meaning depend on the position in a tuple, will be very difficult to maintain.

A third principle is error prevention. This matters in the context of components/APIs used by a lot of developers. Especially when misunderstandings could easily arise but errors would stay undetected (e.g. no type inconsistency could be catched). This is why for example Swift allows parameter passing by name.

The rest is preference.

Compactness is IMHO not a valid argument. It’s far more expensive to have a productive system crashed, than typing some extra characters.

For example, if the data is 100000 entries large

If the data would be so large, I doubt that you would hard code it into a programming language construct.

You would probably want to have is in a file and you are free to chose the format. But the best choice depends on the larger context:

• you could use a very expressive and self-documenting JSON format, but which is not easy for end-users to produce without an app;
• or you can chose a tabular format, with two columns, and a clear title for the each column. It’d be easier to produce and maintain with a text editor or a spreadsheet, but every single record taken on its own would appear less understandable.

Would you really chose between compactness or readability here ? Wouldn’t you seek to achieve reliability and ease of use first, by providing an app to the user for maintaining this huge amount of data ?