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.
Any such search and replace should be performed with care and each change manually checked to eg avoid "accompany" in a comment becoming "acvendor" with your company/vendor change. As such, two separate searches for "company" and "companies" should not create a significant overhead compared with the time spent inspecting and approving each change.
So misspelling words to achieve only one search offers the negatives of looking bad and being more difficult to read than it need be, without offering any obvious benefit.
I'm assuming you're talking about renaming in source code files. With today's IDEs this should always be done with the IDE's refactoring tools. If your IDE doesn't have this, consider switching to another IDE. Most IDE refactoring tools also keep a history of refactoring, giving you the ability to quickly "undo" if you don't like the results of the refactor. Using search/replace, you may not have the ability to undo the whole set of changes (unless you maybe use your revision control tools and revert to previously committed version). Also, using refactoring tools you're safer from inadvertently changing something you didn't intend to change.
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.