[swift-evolution] Case conventions for mixed-case words (like
jordan_rose at apple.com
Thu May 5 21:43:39 CDT 2016
> On May 5, 2016, at 15:54, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> On Thu, May 5, 2016 at 5:31 PM, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> NaN is really a problem only because of using it as an acronym rather than just having .invalidNumber or .notANumber (little uglier) or something similar instead. This comes back to the annoying consideration between something being prior art, at the cost of potentially defining something that’s better, or a better fit for the language. If NaN didn’t exist elsewhere, would we even consider it at all if we were implementing float point numbers for the first ever time in Swift? I’d prefer we defined something more verbose as an alternative to avoid the acronym entirely.
> When it comes to having iPad conformance the question is; should we ever actually test for names at all? An iPad is a brand, it’s not really something that a program should test for, as what’s important to a program are capabilities. The same is true with testing for an OS, we don’t want to test Windows, Mac etc., but rather to test what libraries are available. Same is true with hardware; it doesn’t matter if a device is an iPad, what matters is that it has a touch-screen rather than a keyboard, that it has a small screen rather than a full monitor, that it’s mobile (and not plugged in) etc.
> Testing for names like that should be avoided at all costs when it comes to variable and method names, and be relegated to string-based tests for when you absolutely have to access that information. In other words programs should be platform agnostic, and only need to know whether capabilities they require or optionally support exist or not.
> For these I’d prefer that the guidelines warn against these in the strongest possible terms, as they’re usually a bad idea IMO.
> Whether using the word iPad is wise or not, the question still remains what to do when encountering a term that looks like that. If I'm writing an app that deals with chemical compounds, how should I name a type that deals with pH? How about a computed property representing pH? Should either or both be PH, pH, or ph? It certainly will not do to say "just name it powerOfHydrogen”.
Right, stating that you don’t like these particular examples or terms of art doesn’t change the need for a proper convention. There will be cases where a term of art is the right thing to use, and that term happens to be conventionally spelled with mixed case. The point of naming guidelines is to provide an answer when the situation does arise; right now they’re ambiguous.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution