I had a private exchange with @dabrahams that was illuminating, and he asked me to post it here (I think he’ll follow-up by making his reply public shortly):
TL;DR
I’m writing all this to justify my convictions that:
- Naming things well in programming is completely orthogonal to the grammatical rules of English language.
- Focus on English grammar is an accessibility barrier for non-native speakers.
- Overly prescriptive rules are harmful to the living language, hindering creativity and responsible use.
Based on this and other fragments, I might be misunderstanding your aim here, Dave, but you seem to be searching for some kind of rule based system to automate naming decisions.
I don’t think that’s an fruitful direction. To illustrate: I’ve been told several times that for a non-native speaker, my command of English language is above average. But reading the above quote, I had to look up dictionary definition of preposition, to understand what you meant. I’m still not sure I fully grasp your point. People very rarely perform grammar analysis in everyday life. When using a language, we go by our gut feeling and say or write what feels natural, without thorough consideration of all the formal rules. This applies to the use of English and programming languages alike.
You seem to be looking for some kind of amendment to the API naming guidelines that would ground naming decisions in a set of English-grammar-based rules. This approach might have been useful during the big rename, when performing automated conversions form the corpus of Objective-C method names. Even then I recall a linguist pointing out to you that English is inconsistent and shouldn’t be treated like a ruleset.
From Java I remember quite prevalent rule for naming Boolean variables and methods using prefix “is”. From my experience of striving for fluent interface, I find that dogmatic adherence to such simplistic rules actually hinders readability at the point of use. The clarity is achieved by considerate construction of a domain specific vocabulary that slots in naturally into the shape provided by used framework. It’s a result of responsible application of judgment, not automated rules.
Regarding the question from core team about the weighing choices of the different argument labels, the above argument logically leads to choosing the 3rd option, studentBody.containsOnly(gradeIsAPlus):
On the other hand I fully support the concise term-of-art based name .all(satisfy:), including the clarifying argument label. I don’t think we should be going for rule based guideline amendment to justify this choice.
The over-reliance on English grammar creates accessibility barrier for non-native speakers. There’s something wrong when I need to consult dictionary to write Swifty code. The few prescriptive rules we currently have in the guidelines do go a long way and I fully support them. Extending them further with references to arcane English-grammar minutia isn’t really helping and as a second degree effect it creates a justification for bikeshedding, fueling unhelpful forms of pedantry and aggressive lawyering during naming discussions. In spirit of the essay “What Is 'Correct' Language?”, I hope we will reconsider the prescriptivist approach. If an amendment to guidelines is really necessary, I hope we can describe how to strive for fluency by adding more illustrative examples.
I argue for going with even lighter touch: de-emphasize the grammar reference in the guidelines.
If I misunderstood your aim, I’m sorry for wasting your time. If this argument convinced you, feel free to quote me publicly. If your experience lead you to a different persuasion, I’m eager to learn more about it!