Woohoo! One more of my "Programmers SE" answers has received a score of -5 !

The question is on a controversial topic, and as usual, I take the controversial stance.  So, it is no wonder that people do not agree with me.

Here is the question:

programmers.stackexchange.com: Does it make sense to use “ys” instead of “ies” in identifiers to ease find-and-replace functionality?

Update:

It turns out that the question was closed as "primarily opinion based", so I am saving the question and my answer here for posterity.

The question:

Does it make sense to use “ys” instead of “ies” in identifiers to ease find-and-replace functionality? [closed]

Although grammatically incorrect, when writing identifiers for functions, variables etc. does it make sense to simply append an "s" to plurals of words ending in Y? My reason for this would be that if you need to find-and-replace, for example, replacing "company" with "vendor", "company" would match both singular and plural forms ("company and "companys"), whereas if the plural was spelled correctly, you would have to do two separate searches.

My answer:

Yes! Yes! Yes!  It makes perfect sense to do that.  And I have been doing it for years.

Disclosure 1: English is not my native language.

Disclosure 2: My knowledge of English grammar is considerably better than that of the average native speaker.

Disclosure 3: When it comes to communicating with humans, I am a vehement grammar Nazi.

And now that these disclosures are out of the way, let me state that English grammar has no place in code.  You see, that's why it is called code and not prose.  It is supposed to have some resemblance to a language understood by humans, for the purpose of readability, but other than that, what we mostly need from code is not the qualities of prose; it is other, more technical qualities, like precision, unambiguity, and terseness.  That's why the C syntax of `if( x != y ) y++;` is much preferable to the `IF X IS NOT EQUAL TO Y THEN ADD 1 TO Y END-IF.` syntax of Cobol.  The alleged desirability of compilers that understand natural language is a fallacy, and don't take my word for it, see what ol'Edsger has to say about it: Edsger W. Dijkstra, On the foolishness of "natural language programming".

Another quality which is of importance is computability of identifiers.  The fact that a property called `Color` can always be read via a method called `getColor()` and written via a method called `setColor()` is of paramount importance.  These identifiers are computable from the name of the property, so you do not have to know them by heart. If a programmer was to choose a pair of methods called `getColor()` on one hand, but `colorize()` on the other hand, their colleagues would rightfully consider this sabotage.  That's how important identifier computability is.

Also, programming tools can be written (and plenty of them have in fact been written, for example, *Hibernate*) which can compute these names. Without identifier name computability you would have to use additional syntax (e.g. in Hibernate, extra annotations) to specify to each tool precisely how to create every single identifier name, or precisely which ad hoc name you have given to each entity.

So, identifier computability is important, while at the same time English grammar is irrelevant, (since we are not doing natural language programming,) so to be able to compute the name of a collection of entities by *always* appending "s" to the name of a single instance makes perfect sense, never mind the fact that it violates most people's (mine included) English language sensitivities.

And whether we like it or not, this is the trend of the future.  The native language of the majority of programmers on the planet is not English anymore, and the trend is to continue *very strong* in this direction.  (Also, I would not even be willing to bet money on the suggestion that English is the native language of the majority of programmers working in the USA right now.) These are people who, to a large extent, when trying to calculate the name of a collection from the name of a single instance of "company", will simply append an "s", and the form "companies" will not even cross their mind.  To a great and ever increasing percentage of programmers in the world, knowledge of the peculiarities of the English language does not add any value to their work, it only makes it slightly harder.