{"id":172,"date":"2008-12-04T02:28:20","date_gmt":"2008-12-04T07:28:20","guid":{"rendered":"http:\/\/vgable.com\/blog\/2008\/12\/04\/cocoa-coding-style-minutia-all-forward-declarations-on-one-line-is-the-one-true-way\/"},"modified":"2010-03-27T17:22:37","modified_gmt":"2010-03-27T22:22:37","slug":"cocoa-coding-style-minutia-all-forward-declarations-on-one-line-is-the-one-true-way","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2008\/12\/04\/cocoa-coding-style-minutia-all-forward-declarations-on-one-line-is-the-one-true-way\/","title":{"rendered":"Cocoa Coding Style Minutia: All Forward Declarations on One Line is the One True Way"},"content":{"rendered":"

This is a very petty point, but I believe there’s a right answer, and since it’s come up before I’m going to take the time to justify the best choice.<\/p>\n

Forward Declare Classes on One Line, Not Many Lines<\/h3>\n

Right:<\/strong>
\n@class Foo, Bar, Baz...;
<\/code><\/p>\n

This is the style that Apple’s headers generally follow, look at NSDocument.h<\/a><\/code> for example.<\/p>\n

Wrong:<\/strong>
\n@class Foo;
\n@class Bar;
\n@class Baz;
\n...
<\/code><\/p>\n

Programming languages are to be read by people first, and interpreted by computers second. I really do hope anyone in software engineering can take that as an axiom! <\/p>\n

Therefore, always favor brevity above all else with statements that are only<\/em> for the compiler. They are by far the least important part of the code base. Keeping them terse minimizes distractions from code that can and should be read.<\/p>\n

Naturally, it’s very hard to find a statement that’s only<\/em> for the compiler. I can only think of one such statement in Objective-C, forward declarations of an object with @class<\/code>.<\/p>\n

What Does @class<\/code> Do?<\/h3>\n

@class Foo;<\/code> tells the compiler that Foo<\/code> is an Objective-C class, so that it knows how much space to reserve in memory for things of type Foo<\/code>. It does not tell the compiler what methods and ivars a Foo<\/code> has, to do that you need to #import \"Foo.h\"<\/code> (or have an @interface Foo...<\/code> in your .m file.)<\/p>\n\n\n\n
@class Foo;<\/code><\/th>\n#import \"Foo.h\"<\/code><\/th>\n<\/tr>\n
Foo<\/code> is a black box. You can only use it as an argument.<\/td>\nYou can also send messages to Foo<\/code>.<\/td>\n<\/tr>\n<\/table>\n

What is @class<\/code> Good For?<\/h3>\n

Since #import \"Foo.h\"<\/code> does everything @class Foo;<\/code> does and more<\/em>, why would you ever use @class<\/code>? The short answer is less time wasted compiling<\/strong>.<\/p>\n

Lets say you have a Controller<\/code> class, and it has an ivar that’s a Foo<\/code>. To get it to compile, you put #import \"Foo.h\"<\/code> inside Controller.h<\/code>. So far so good. The problem comes when Foo.h<\/code> is changed. Now any file that has #import \"Foo.h\"<\/code> in it must be recompiled. So Controller.h<\/code> has to be recompiled. So any file that has #import \"Controller.h\"<\/code> in it must also<\/em> be recompiled, and so on. Many objects that don’t use Foo<\/code> objects, but do talk to the Controller<\/code> (or to something that talks to something that talks to the Controller<\/code>!) have to be rebuilt as well. It’s likely that the entire project would end up being rebuilt. With even a moderately sized project, that means a lot<\/em> of needless compile time!<\/p>\n

One solution is to put a forward-declaration, @class Foo;<\/code>, in Controller.h<\/code>, and #import \"Foo.h\"<\/code> in Controller.m<\/code>, and the few files that actually do something to Foo<\/code> objects. @class Foo;<\/code> gives the compiler just enough information to build an object with a Foo*<\/code> ivar, because it knows how much space that ivar will need in memory. And since only objects that need to talk to Foo<\/code> objects directly have any dependency on Foo.h<\/code>, changes to Foo<\/code> can be tested quickly. The first time I tried this solution in one of my projects, compile times dropped from minutes to seconds.<\/p>\n

Readers Need Less @class<\/code><\/h3>\n

Forward declarations add value to the development process, as does anything that saves programmers time. But @class<\/code> tells a human reader nothing<\/em>. Which is why I say you should use them in your code, but minimize the space they take up, by putting them all on one line.<\/p>\n

@class Foo;<\/code> tells a reader that “Foo<\/code> is black-box that is a class.” That adds no useful information.<\/p>\n

If the reader does not care about what a Foo<\/code> is (they are treating it as a black box), then knowing that Foo<\/code> is a class is useless information. Foo<\/code> could be a struct<\/code>, or a bit-field, or a function pointer, or anything else and they still would not need to know to understand the code.<\/p>\n

Conversely, if they need to know what a Foo<\/code> is to understand the code, then they need to know more then “it is a class”. They need to see Foo.h<\/code> or documentation — @class<\/code> just isn’t enough.<\/p>\n

Exceptions<\/h3>\n

I want to again emphasize that this isn’t a big deal. I strongly feel<\/a> that putting all forward declarations on one line is the right answer, but doing it wrong won’t perceptibly matter in the end.<\/p>\n

So I don’t think there’s any reason to address exceptions to the rule. Do what you gotta do.<\/strong><\/p>\n

Best Practices<\/h3>\n

Use @class<\/code> to speed up compile-times as much as you can, but use the keyword @class<\/code> as little as possible, since it is for the compiler, not the person reading the code.<\/p>\n","protected":false},"excerpt":{"rendered":"

This is a very petty point, but I believe there’s a right answer, and since it’s come up before I’m going to take the time to justify the best choice. Forward Declare Classes on One Line, Not Many Lines Right: @class Foo, Bar, Baz…; This is the style that Apple’s headers generally follow, look at […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,5,4,8],"tags":[240,241,243,158,242,169],"class_list":["post-172","post","type-post","status-publish","format-standard","hentry","category-cocoa","category-objective-c","category-programming","category-usability","tag-class","tag-best-practices","tag-compilers","tag-optimization","tag-programming-style","tag-software-development"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/172","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=172"}],"version-history":[{"count":2,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/172\/revisions"}],"predecessor-version":[{"id":590,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/172\/revisions\/590"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}