On Nov 21, 2014, at 10:09 PM, Daniel Blakemore <dblakem...@pixio.com> wrote:
> I've personally never whined about any of this. I really like have a place
> to put all my documentation that is cleanly separated from where the actual
> work gets done. In larger files, the large headerdoc comments would destroy
> any sense of position in the implementation file with unnecessary bloat.
On Nov 21, 2014, at 7:24 PM, Quincey Morris
<quinceymor...@rivergatesoftware.com> wrote:
> The trouble is that header files basically cause you to replicate source code
> (and source keystrokes).
Here is an example of one of my Objective-C classes.
Header File
2 Enumerations
6 Properties
16 Methods
118 Lines
Source File
2 Properties
75 Methods
2039 Lines
Perhaps it is just me, but it is not uncommon for my source file to have many
more methods than what is in my header. So for me it is not the replicated code
in the header file that is a negative but rather it is being forced to define
the interface that ends up being a positive.
My documentation style is patterned after Richard Hipp’s SQLite project where a
detailed description of each interface routine is found in the source code. A
quick glance at the header file gives you an overview of the interface. If you
need more information then go to the source code.
Overall this results in smaller header files and a more readily comprehended
interface. I find this very beneficial when working with a large project, it
help me keep my sanity.
Richard Charles
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
