I think is has value for code to be idiomatic. It's a very dynamic goal post for sure, which is a problem in a rule but not in a principle like in the article.

I think is has value for code to be idiomatic. It's a very dynamic goal post for sure, which is a problem in a rule but not in a principle like in the article. To me, code that is not idiomatic sounds wrong, which is at least a cognitive hurdle (you need to spend more thinking power to unravel/decode it to figure out the meaning). I believe this is in line with the usage regarding natural (human) languages. A sentence might be syntactically correct but if its non-idiomatic it sounds wrong and throws the listener(s) for a loop understanding it. A very simple example is that in C, I greatly favor allocations to be written according to: P = malloc(N * sizeof *P) where P is the pointer variable receiving the return value, and N is an expression yielding the number of desired elements. The sizeof is completely idiomatic, always present unless I'm allocating an actual byte buffer, and always de-references P like that to lock the size to the receiving pointer. So this is my idiom for how an allocation is written. It might (should!) be yours, too but that's not a requirement in a personal principle I guess.