Terminology-wise, most of these are not acronyms <https://en.wiktionary.org/wiki/acronym#Noun> (or initialisms <https://en.wiktionary.org/wiki/initialism#Noun>), but you’re right that that’s a third option consistent with the existing guidelines.
Jordan > On May 5, 2016, at 08:56, Basem Emara <cont...@basememara.com> wrote: > > Yes I digress and agree with you consistency is absolute key. Another thought > came to mind: > > Option 3 3: Uppercase all acronyms including those with mixed casing. This is > both consistent and clear. Isolating acronyms is important because they loose > their meaning and bleed into word boundaries, so making even mixed acronyms > all uppercase clearly identifies them. In context, that might be > “supportsIPAD”, “LATEXRenderer”, “isNEXTPlatform”, and “signalingNAN”, > alongside “IPADIcon”, “LATEXSource”, “NEXTLogo”, and “NANValue”.) > >> On May 5, 2016, at 11:41 AM, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >> [resending to include list] >> >> Hm. I’m not sure why these words would be special, though—if we were going >> to use underscores, shouldn’t we consistently go for “snake_case” or >> something? >> >> (A leading underscore is also often used to denote something private in a >> lot of conventions, including the standard library.) >> >> Jordan >> >> >>> On May 5, 2016, at 08:38, Basem Emara <cont...@basememara.com >>> <mailto:cont...@basememara.com>> wrote: >>> >>> Indeed the scenario has always been tricky for conventions. In both option >>> 1 and 2, it looses the meaning, so I propose option 3 (which still sux too >>> ha): >>> >>> Option 3: Surround with underscores to isolate the acronym with mixed >>> casing. It clearly retains the original meaning since acronys already >>> create ambigiouty. An added degree of ambiguity could lose it’s meaning >>> complete. This way with underscores, it is clear what it is referring to. >>> In context, that might be “supports_iPad”, “_LaTeX_Renderer”, >>> “is_NeXT_Platform”, and “signaling_NaN”, alongside “_iPad_Icon”, >>> “_LaTeX_Source”, “_NeXT_Logo”, and “_NaN_Value”.) >>> >>>> On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> Hi, everyone. Today in the API Design Guidelines >>>> <https://swift.org/documentation/api-design-guidelines/> we have this >>>> section on case: >>>> >>>>> Follow case conventions. Names of types and protocols are UpperCamelCase. >>>>> Everything else is lowerCamelCase. >>>>> >>>>> Acronyms and initialisms that commonly appear as all upper case in >>>>> American English should be uniformly up- or down-cased according to case >>>>> conventions: >>>>> >>>>> var utf8Bytes: [UTF8.CodeUnit] >>>>> var isRepresentableAsASCII = true >>>>> var userSMTPServer: SecureSMTPServer >>>>> >>>>> Other acronyms should be treated as ordinary words: >>>>> >>>>> var radarDetector: RadarScanner >>>>> var enjoysScubaDiving = true >>>> >>>> However, this doesn't directly address words that are conventionally >>>> written with mixed case. Usually these are names, such as "iPad", "LaTeX", >>>> or “NeXT”, but sometimes they’re just acronyms or initialisms with very >>>> strong conventions, like “NaN”. (Yes, the FloatingPoint proposal is what >>>> prompted this whole thing.) >>>> >>>> There are a few options for what we could do with these words to make them >>>> consistent with our existing rules for words that are all-uppercase, >>>> all-lowercase, or capitalized (first letter uppercase, remaining letters >>>> lowercase). It’s pretty clear from the “utf8Bytes” example above that use >>>> at the start of a “lowerCamelCase” identifier means uniformly downcasing >>>> all of the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear >>>> exactly what operation is being applied to subsequent words in an >>>> identifier: >>>> >>>> Option 1: Upcase the first letter, leave all the other letters alone. This >>>> is consistent with all of the examples shown in the API design guidelines, >>>> and produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, that might >>>> be “supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and “signalingNaN”, >>>> alongside “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.) >>>> >>>> Option 2: If any letters are lowercase, upcase the first letter and >>>> downcase all other letters. This is also consistent with all of the >>>> examples shown in the API design guidelines, and produces “Ipad”, “Latex”, >>>> “Next”, and “Nan”. (In context, that’s “supportsIpad”, “LatexRenderer”, >>>> “isNextPlatform”, and “signalingNan”, alongside “ipadIcon”, “latexSource”, >>>> “nextLogo”, and “nanValue”.) >>>> >>>> I prefer option 1 because I think it’s easier to recognize the original >>>> form of the word; DaveA notes that under option 2 it’s easier to find the >>>> word boundaries. >>>> >>>> (“NeXT” is an especially tricky case because without case it’s not >>>> distinguishable from the normal word “next”. This situation is rare but >>>> not nonexistent. Then again, “Apple” is not distinguishable from the >>>> normal word “apple” either, and we seem to do fine there.) >>>> >>>> Thoughts? >>>> Jordan >>>> >>>> P.S. The rules also don’t special-case all-lowercase initialisms, like >>>> “mph” (for “miles per hour”). Under either option above, we’d get “Mph”. >>>> If we want some other behavior, >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
