{"id":3295,"url":"https://github.com/NYTimes/objective-c-style-guide","last_synced_at":"2025-08-13T19:33:13.184Z","repository":{"id":37579913,"uuid":"11797828","full_name":"nytimes/objective-c-style-guide","owner":"nytimes","description":"The Objective-C Style Guide used by The New York Times","archived":true,"fork":false,"pushed_at":"2023-05-09T17:23:08.000Z","size":277,"stargazers_count":5850,"open_issues_count":0,"forks_count":1261,"subscribers_count":358,"default_branch":"master","last_synced_at":"2024-09-27T04:21:55.334Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://open.blogs.nytimes.com/2013/08/01/objectively-stylish/","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nytimes.png","metadata":{"files":{"readme":"README-FRA.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2013-07-31T18:21:46.000Z","updated_at":"2024-09-22T17:33:22.000Z","dependencies_parsed_at":"2022-07-12T16:24:42.786Z","dependency_job_id":"eccf2f8d-a113-46ed-939c-57237dafde51","html_url":"https://github.com/nytimes/objective-c-style-guide","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nytimes%2Fobjective-c-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nytimes%2Fobjective-c-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nytimes%2Fobjective-c-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nytimes%2Fobjective-c-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nytimes","download_url":"https://codeload.github.com/nytimes/objective-c-style-guide/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":229780026,"owners_count":18122914,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-01-05T20:16:37.355Z","updated_at":"2024-12-15T03:30:27.599Z","avatar_url":"https://github.com/nytimes.png","language":null,"funding_links":[],"categories":["Style Guides","Objective-C","Programming Languages","Unofficial","非官方","代码规范\u0026设计模式","WebSocket","Others","Uncategorized"],"sub_categories":["Keychain","Vue","Objective-C","Other Xcode","\u003ca name=\"other-xcode\"\u003e\u003c/a\u003e其他 Xcode 插件","Other free courses","Misc","Uncategorized"],"readme":"# NYTimes - Guide de Style Objective-C\n\nCe guide décrit les conventions de codage des équipes iOS du New York Times. Nous vous remercions pour vos commentaires dans les [tickets](https://github.com/NYTimes/objetive-c-style-guide/issues), [pull requests](https://github.com/NYTimes/objetive-c-style-guide/pulls) et [tweets](https://twitter.com/nytimesmobile). Aussi, [nous recrutons](http://jobs.nytco.com/job/New-York-iOS-Developer-Job-NY-10001/73366300/).\n\nMerci à tous [nos contributeurs et contributrices](https://github.com/NYTimes/objective-c-style-guide/contributors).\n\n## Introduction\n\nVoici quelques-uns des documents d'Apple qui nous ont servi à écrire ce guide. Si quelque chose n'est pas mentionné ici, il est probablement couvert en détail dans\u0026#8239;:\n\n* [Le langage de Programmation Objective-C](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html)\n* [Les Bases Fondamentales de Cocoa](https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/Introduction.html)\n* [Conseils Généraux de Codage pour Cocoa](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html)\n* [Guide de Programmation pour App iOS](http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/Introduction/Introduction.html)\n\n## Table des matières\n\n* [Notation pointée](#notation-pointée)\n* [Espacement](#espacement)\n* [Conditions](#conditions)\n  * [Opérateur ternaire](#opérateur-ternaire)\n* [Gestion des erreurs](#gestion-des-erreurs)\n* [Méthodes](#méthodes)\n* [Variables](#variables)\n* [Nommage](#nommage)\n* [Commentaires](#commentaires)\n* [Init \u0026 Dealloc](#init-et-dealloc)\n* [Libellés](#libellés)\n* [Fonctions CGRect](#fonctions-cgrect)\n* [Constantes](#constantes)\n* [Types énumérés](#types-énumérés)\n* [Masques de bits](#masques-de-bits)\n* [Propriétés privées](#propriétés-privées)\n* [Nommage d'image](#nommage-dimage)\n* [Booléens](#booléens)\n* [Singletons](#singletons)\n* [Imports](#imports)\n* [Projet Xcode](#projet-xcode)\n\n## Notation pointée\n\nLa notation pointée doit **toujours** être utilisée pour lire ou modifier les propriétés. La notation crochée est préférable dans tous les autres cas.\n\n**Par exemple:**\n```objc\nview.backgroundColor = UIColor.orangeColor;\nUIApplication.sharedApplication.delegate;\n```\n\n**Non pas:**\n```objc\n[view setBackgroundColor:[UIColor orangeColor]];\n[UIApplication sharedApplication].delegate;\n```\n\n## Espacement\n\n* L'indentation est de 4 espaces. N'indentez jamais avec des tabulations. Assurez-vous de régler cette préférence dans Xcode.\n* L'accolade ouvrante des méthodes et structures de contrôle (`if`/`else`/`switch`/`while` etc.) est toujours sur la même ligne que la déclaration et l'accolade fermante sur sa propre ligne. \n\n**Par exemple:**\n```objc\nif (utilisateur.estHeureux) {\n    //Faire quelque chose\n}\nelse {\n    //Faire quelque chose d'autre\n}\n```\n* Les méthodes devraient être séparées par une ligne blanche pour améliorer la lisibilité et l'organisation. À l'intérieur des méthodes, des sauts de lignes devraient séparer les sections logiques, mais souvent ces dernières devraient être placées dans de nouvelles méthodes.\n* `@synthesize` et `@dynamic` devraient chacun être déclarés sur de nouvelles lignes dans l'implémentation.\n\n## Conditions\n\nLes instructions de condition doivent toujours utiliser des accolades même quand la condition pourrait être écrite sans (par ex. sur une seule ligne) pour éviter des [erreurs](https://github.com/NYTimes/objective-c-style-guide/issues/26#issuecomment-22074256). Une de ces erreurs serait d'ajouter une deuxième ligne et de penser qu'elle fait partie de la condition. Une autre, [plus dangereuse](http://programmers.stackexchange.com/a/16530) peut arriver quand la ligne «\u0026#8239;intérieure\u0026#8239;» de la condition est commentée, et la prochaine ligne devient involontairement une partie de la condition. De plus, ce style est plus cohérent avec d'autres conditions et donc plus facile à détecter.\n\n**Par exemple:**\n```objc\nif (!error) {\nreturn success;\n}\n```\n\n**Non pas:**\n```objc\nif (!error)\nreturn success;\n```\n\nou\n\n```objc\nif (!error) return success;\n```\n\n### Opérateur ternaire\n\nL'opérateur ternaire, `?` , doit seulement être utilisé s'il rend le code plus lisible ou propre. Il doit seulement évaluer une condition simple. Évaluer plusieurs conditions est généralement plus facile à comprendre avec une condition de type if, ou refactorisé avec des variables nommées.\n\n**Par exemple:**\n```objc\nresult = a \u003e b ? x : y;\n```\n\n**Non pas:**\n```objc\nresult = a \u003e b ? x = c \u003e d ? c : d : y;\n```\n\n## Gestion des erreurs\n\nQuand une méthode renvoie un paramètre d'erreur par référence, continuez l'exécution du programme sur la valeur returnée, et non sur la variable erreur.\n\n**Par exemple:**\n```objc\nNSError *error;\nif (![self FaireQuelqueChoseAvecErreur:\u0026error]) {\n// Gérer l'erreur\n}\n```\n\n**Non pas:**\n```objc\nNSError *error;\n[self FaireQuelqueChoseAvecErreur:\u0026error];\nif (error) {\n// Gérer l'erreur\n}\n```\n\nCertaines APIs d'Apple renvoient des valeurs de données poubeille pour un paramètre erreur (si non-NULL), donc continuer l'exécution du programme sur l'erreur peut créer des faux négatifs (et par la suite un plantage).\n\n## Méthodes\n\nPour la signature d'une méthode, il doit y avoir un espace après le scope (symbole `-` ou `+`). Et il doit y avoir un espace entre les différents segments (paramètres) de la méthode.\n\n**Par exemple**:\n```objc\n- (void)setTextePourExemple:(NSString *)texte image:(UIImage *)image;\n```\n## Variables\n\nLes variables doivent être nommées de la façon la plus descriptive possible. Une variable d'une seule lettre doit être évitée sauf pour une boucle `for`.\n\nLes astérisques qui indiquent le pointeur sont plaçés avant le nom de la variable, par ex., `NSString *text` et non `NSString* text` ou `NSString * text`, sauf dans le cas de constantes (`NSString * const NYTConstantString`).\n\nLa définition des propriétés doivent être utilisées à la place des variables d'instance quand c'est possible. L'accès direct aux variables d'instance doit être évité sauf pour les méthodes d'initialisation (`init`, `initWithCoder:`, etc…), la méthode `dealloc` et les accesseurs et mutateurs. Pour plus d'information sur l'utilisation de méthodes d'accès, les méthodes d'initialisation et dealloc, consultez [cet article](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW6).\n\n**Par exemple:**\n\n```objc\n@interface NYTSection : NSObject\n\n@property (nonatomic) NSString *headline;\n\n@end\n```\n\n**Non pas:**\n\n```objc\n@interface NYTSection : NSObject {\nNSString *headline;s\n}\n```\n\n#### Qualification des variables\n\nEn ce qui concerne les qualificateurs de variables [introduits avec ARC](https://developer.apple.com/library/ios/releasenotes/objectivec/rn-transitioningtoarc/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW4), le qualificateur (`__strong`, `__weak`, `__unsafe_unretained`, `__autoreleasing`) doit être placé entre l'astérisque et le nom de la variable, par ex., `NSString * __weak text`.\n\n## Nommage\n\nLa convention de nommage Apple devrait être suivie quand possible, surtout en ce qui concerne les [règles de management de mémoire](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html) ([NARC](http://stackoverflow.com/a/2865194/340508)).\n\nIl est mieux d'utiliser des noms descriptifs, et longs si nécessaire, pour les méthodes et variables.\n\n**Par exemple:**\n\n```objc\nUIButton *settingsButton;\n```\n\n**Non pas**\n\n```objc\nUIButton *setBut;\n```\n\nUn préfixe de trois lettres (par ex. `NYT`) doit toujours être utilisé pour le nom des classes et constantes, mais peut être omis pour le nom des entités dans Core Data. Les constantes doivent adopter la convention camelCase avec tous les mots qui commencent avec une lettre capitale, précédées du nom de la classe dans laquelle ils sont déclarés pour la clarté.\n\n**Par exemple:**\n\n```objc\nstatic const NSTimeInterval NYTArticleViewControllerNavigationFadeAnimationDuration = 0.3;\n```\n\n**Non pas:**\n\n```objc\nstatic const NSTimeInterval fadetime = 1.7;\n```\n\nLes properties et variables locales doivent adopter la convention camelCase avec le premier mot en minuscules.\n\nLes variables d'instance doivent adopter la convention camelCase avec le premier mot en miniscules, précédé par le préfixe  «\u0026#8239;_\u0026#8239;». Ceci est cohérent avec les variables d'instance synthetisées automatiquement par LLVM. **Si LLVM peut synthetiser la variable automatiquement, laissez-le faire.**\n\n**Par exemple:**\n\n```objc\n@synthesize nomDeVariableDescriptif = _nomDeVariableDescriptif;\n```\n\n**Non pas:**\n\n```objc\nid nmvar;\n```\n\n## Commentaires\n\nSi nécessaire, les commentaires peuvent être utilisés pour expliquer **pourquoi** un bloc de code fait quelque chose. Les commentaires doivent être à jour ou éliminés.\n\nLes paragraphes de commentaires devraient généralement être évités, le code devrait être suffisament descriptif, avec seulement un besoin intermittent de commentaire et juste quelques lignes d'explications. Ceci ne s'applique pas aux commentaires utilisés pour la documentation.\n\n## init et dealloc\n\nLa méthode `dealloc` doit être placée au début de l'implémentation, directement après les expressions `@synthesize` et `@dynamic`. La méthode `init` doit être placée directement après la méthode `dealloc`.\n\nLa méthode `init` doit être structurée comme ceci:\n\n```objc\n- (instancetype)init {\nself = [super init]; // ou appeler l'initialisateur désigné\nif (self) {\n// Initialisation particulière à cet object\n}\nreturn self;\n}\n```\n\n## Libellés\n\n`NSString`, `NSDictionary`, `NSArray`, et `NSNumber` literals doivent être utilisés quand des instances immutables sont créées pour ces objets. Faites bien attention que la valeur `nil` ne soit pas passée aux literals `NSArray` et `NSDictionary`, parce que ça causerait un plantage.\n\n**Par exemple:**\n\n```objc\nNSArray *names = @[@\"Brian\", @\"Craig\", @\"Véronique\"];\nNSDictionary *productManagers = @{@\"iOS\": @\"Andrew\", @\"Android\": @\"Kate\"};\nNSNumber *shouldUseLiterals = @YES;\nNSNumber *buildingZIPCode = @10018;\n```\n\n**Non pas:**\n\n```objc\nNSArray *names = [NSArray arrayWithObjects:@\"Brian\", @\"Craig\", @\"Véronique\", nil];\nNSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @\"Andrew\", @\"iOS\", @\"Kate\", @\"Android\", nil];\nNSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];\nNSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018];\n```\n\n## Fonctions `CGRect`\n\nEn accédant à `x`, `y`, `width`, ou `height` d'un `CGRect`, utilisez toujours les [fonctions `CGGeometry`](https://developer.apple.com/documentation/coregraphics/cggeometry) au lieu de l'accès direct au membre struct. Extrait de la référence Apple pour `CGGeometry`:\n\n\u003e Toutes les fonctions décrites dans cette référence qui prendre les structures de data CGRect comme donnée standardise implicitement ces rectangles avant de calculer leurs résultats. Pour cette raison, votre application devrait éviter de lire et écrire directement la donnée sauvegardée dans la structure de données CGRect. À la place, utilisez les fonctions décrites ici pour manipuler les rectangles et pour recupérer leurs caractériques.\n\n**Par exemple:**\n\n```objc\nCGRect frame = self.view.frame;\n\nCGFloat x = CGRectGetMinX(frame);\nCGFloat y = CGRectGetMinY(frame);\nCGFloat width = CGRectGetWidth(frame);\nCGFloat height = CGRectGetHeight(frame);\n```\n\n**Non pas:**\n\n```objc\nCGRect frame = self.view.frame;\n\nCGFloat x = frame.origin.x;\nCGFloat y = frame.origin.y;\nCGFloat width = frame.size.width;\nCGFloat height = frame.size.height;\n```\n\n## Constantes\n\nLes constantes sont préférables aux literals in-line ou aux nombres, parce qu'elles peuvent être facilement reproduites de variables utilisés souvent et parce qu'elles peuvent être changées facilement sans avoir besoin de faire une recherche. Constantes devraient être déclarées avec `static` et non pas `#define`s à moins qu'elle soient utilisées explicitement comme macro.\n\n**Par exemple:**\n\n```objc\nstatic NSString * const NYTAboutViewControllerCompanyName = @\"The New York Times Company\";\n\nstatic const CGFloat NYTImageThumbnailHeight = 50.0;\n```\n\n**Non pas:**\n\n```objc\n#define CompanyName @\"The New York Times Company\"\n\n#define thumbnailHeight 2\n```\n\n## Types énumérés\n\nPour l'utilisation d' `enum`, il est recommendé de choisir le type fixe spécifié avec un «\u0026#8239;_\u0026#8239;» parce qu'il est de type fort et pour bénéficier de la complétion de code. Le SDK inclus maintenant un macro pour faciliter et encourager l'utilisation de type fixe et souligné — `NS_ENUM()`\n\n**Exemple:**\n\n```objc\ntypedef NS_ENUM(NSInteger, NYTAdRequestState) {\nNYTAdRequestStateInactive,\nNYTAdRequestStateLoading\n};\n```\n\n## Masques de bits\n\nQuand vous travaillez avec des masques de bits, utilisez le macro `NS_OPTIONS`.\n\n**Exemple:**\n\n```objc\ntypedef NS_OPTIONS(NSUInteger, NYTAdCategory) {\nNYTAdCategoryAutos      = 1 \u003c\u003c 0,\nNYTAdCategoryJobs       = 1 \u003c\u003c 1,\nNYTAdCategoryRealState  = 1 \u003c\u003c 2,\nNYTAdCategoryTechnology = 1 \u003c\u003c 3\n};\n```\n\n## Propriétés privées\n\nLes propriétés privées doivent être déclarées dans l'extension de la classe dans le fichier d'implémentation.\n\n**Par exemple:**\n\n```objc\n@interface NYTAdvertisement ()\n\n@property (nonatomic) GADBannerView *googleAdView;\n@property (nonatomic) ADBannerView *iAdView;\n@property (nonatomic) UIWebView *adXWebView;\n\n@end\n```\n\n## Nommage d'image\n\nLes noms des images doit être cohérents pour préserver une bonne organisation. Elles doivent être nommées en utilisant la convention camelCase avec la description de leur utilisation, suivi du suffixe de la classe ou propriété qu'elles customisent (si elle existe), suivie de la description de la couleur et/ou emplacement, et finalement leur état.\n**Par exemple:**\n\n* `RefreshBarButtonItem` / `RefreshBarButtonItem@2x` and `RefreshBarButtonItemSelected` / `RefreshBarButtonItemSelected@2x`\n* `ArticleNavigationBarBlanc` / `ArticleNavigationBarBlanc@2x` and `ArticleNavigationBarNoirSelected` / `ArticleNavigationBarNoirSelected@2x`.\n\nLes images qui sont utilisées à des fins similaires doivent être regroupées dans leurs groupes respectifs à l'intérieur d'un dossier Images ou d'un «\u0026#8239;Asset Catalog\u0026#8239;».\n\n\n## Booléens\n\nPuisque `nil` est retourné comme `NO` il n'est pas nécessaire de le comparer dans une condition. Ne comparez jamais quelque chose avec `YES`, parce que `YES` est défini comme 1 et un `BOOL` peut aller jusqu'à 8 bits.\n\nCe style permet une plus grande cohérence entre les différents fichiers et une meilleure clarté visuelle.\n\n**Par exemple:**\n\n```objc\nif (!unObject) {\n}\n```\n\n**Non pas:**\n\n```objc\nif (unObject == nil) {\n}\n```\n\n-----\n\n**Pour un `BOOL`, voici deux exemples:**\n\n```objc\nif (estSuper)\nif (!unObject.boolValue)\n```\n\n**Non pas:**\n\n```objc\nif (estSuper == YES) // Ne faites pas ça\nif (unObject.boolValue == NO)\n```\n\n-----\n\nSi le nom d'une propriété `BOOL` est exprimée comme un adjectif, la propriété peut omettre le prefixe «\u0026#8239;is\u0026#8239;» mais doit specifier un nom conventionel pour l'accesseur get, par exemple:\n\n```objc\n@property (assign, getter=isEditable) BOOL editable;\n```\nVoyez le document et exemple pris de [Conseils Généraux de Nommage Cocoa](https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE).\n\n## Singletons\n\nLes singletons doivent utiliser un patron thread-safe (état de processus cohérent sans engendrer de problèmes de concurrence) pour créer leur instance unique et partagé.\n\n```objc\n+ (instancetype)sharedInstance {\nstatic id sharedInstance = nil;\n\nstatic dispatch_once_t onceToken;\ndispatch_once(\u0026onceToken, ^{\nsharedInstance = [[[self class] alloc] init];\n});\n\nreturn sharedInstance;\n}\n```\nCelui permet d'éviter des [plantages possibles, et parfois fréquents](http://cocoasamurai.blogspot.com/2011/04/singletons-your-doing-them-wrong.html).\n\n## Imports\n\nS'il y a plusieurs directives d'importation, divisez-les en [groupes](http://ashfurrow.com/blog/structuring-modern-objective-c).\nCommenter chaque groupe est facultatif.\n\nNote\u0026#8239;: pour les modules utilisez la syntaxe [@import](http://clang.llvm.org/docs/Modules.html#using-modules).\n\n```objc\n// Frameworks\n@import QuartzCore;\n\n// Models\n#import \"NYTUser.h\"\n\n// Views\n#import \"NYTButton.h\"\n#import \"NYTUserView.h\"\n```\n\n## Projet Xcode\n\nLes fichiers physiques doivent être maintenus en accordance avec le projet Xcode pour éviter d'avoir des fichiers éparpillés. Les groupes crées dans Xcode doivent avoir un dossier équivalent dans le système de fichiers. Le code doit être groupé non seulement par type, mais aussi par caractéristique pour une plus grande clarté.\n\nSi possible, choisissez toujours «\u0026#8239;Treat Warnings as Errors\u0026#8239;» dans le Build Settings du target et exposer autant d'[avertissements supplémentaires](http://boredzo.org/blog/archives/2009-11-07/warnings) que possible. Si vous avez besoin d'ignorer un avertissement specifique, utiliser [Clang's pragma feature](http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas).\n\n# Autres guides de style Objective-C\n\nSi le nôtre n'est pas à votre goût, consultez ces autres guides:\n\n* [Google](https://google.github.io/styleguide/objcguide.xml)\n* [GitHub](https://github.com/github/objective-c-conventions)\n* [Adium](https://trac.adium.im/wiki/CodingStyle)\n* [Sam Soffes](https://gist.github.com/soffes/812796)\n* [CocoaDevCentral](http://cocoadevcentral.com/articles/000082.php)\n* [Luke Redpath](http://lukeredpath.co.uk/blog/2011/06/28/my-objective-c-style-guide/)\n* [Marcus Zarra](http://www.cimgf.com/zds-code-style-guide/)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FNYTimes%2Fobjective-c-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FNYTimes%2Fobjective-c-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FNYTimes%2Fobjective-c-style-guide/lists"}