Winforms has some gems: DataGridViewColumnDividerDoubleClickEventArgs ListViewVirtualItemsSelectionRangeChangedEventHandler
https://github.com/mattl/opensource.apple.com/blob/88cbaab4a...
71–80 of 188 posts
Winforms has some gems: DataGridViewColumnDividerDoubleClickEventArgs ListViewVirtualItemsSelectionRangeChangedEventHandler
https://github.com/mattl/opensource.apple.com/blob/88cbaab4a...
Well, there's CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter, which is two letters longer than CNLabelContactRelationElderCousinMothersSiblingsDaughterOrFathersSistersDaughter. https://developer.apple.com/documentation/contacts/cnlabelco... This is my favorite topic.
Earlier quoted context omitted.
And off by one errors
If only there were 1 based PLs.
I'm grateful that Apple at least prefixed this. IIRC, between iOS 11 and 12, Apple added a Contact class somewhere within their standard set of frameworks. I was maintaining an app that used CoreData as a store and did not have prefixed Core Data entity names. And of course it had its own Contact class. Long story short, I started building against the newer SDK and the app started crashing in the most oblique way pos…
I'm grateful that Apple at least prefixed this. IIRC, between iOS 11 and 12, Apple added a Contact class somewhere within their standard set of frameworks. I was maintaining an app that used CoreData as a store and did not have prefixed Core Data entity names. And of course it had its own Contact class. Long story short, I started building against the newer SDK and the app started crashing in the most oblique way pos…
Apple recommends to use at least a three character prefix in your objective-c classes to avoid collisions.
At first glance this looked like a code smell, but after some reflection I can't think of a cleaner, more readable way to uniquely identify each possible relationship -- especially in a strongly-typed language with an IDE. Here's the full list: https://developer.apple.com/documentation/contacts/contacts_...
You need an intermediate representation (like a tree) rather than attempt to brute force every possible permutation up until some arbitrary point. Even if that weren't the case, it'd be better to give it a more obscure name or create some kind of naming system and then document it rather than demonstrate why self-documenting code can become self-defeating if taken to an extreme.
A second issue is, this is probably a localisation / cultural concern: below, yorwba notes that this relationship is a specific term in chinese kinship: https://en.wikipedia.org/wiki/Chinese_kinship#Common_extende....
表姐, in case you were wondering.
Looks like this constant should be parsed as: ElderCousin && (MothersSiblingsDaughter || FathersSistersDaughter)
FYI, Mother's Sibling is 舅舅 (Mother's Brothers) or 姨 (Mother's Sisters), and Father's Sister is 姑姑.
At first glance this looked like a code smell, but after some reflection I can't think of a cleaner, more readable way to uniquely identify each possible relationship -- especially in a strongly-typed language with an IDE. Here's the full list: https://developer.apple.com/documentation/contacts/contacts_...
You need an intermediate representation (like a tree) rather than attempt to brute force every possible permutation up until some arbitrary point. Even if that weren't the case, it'd be better to give it a more obscure name or create some kind of naming system and then document it rather than demonstrate why self-documenting code can become self-defeating if taken to an extreme.