Google Releases Objective C Toolbox
By 
Google has released an eclectic set of tools for Mac and iPhone developers called “Google Toolbox for Mac” in an attempt to share some sample code, conventions, and tools that Google believes Mac developers could use for inspiration. The toolbox is licensed under the open Apache License 2.0 and includes:
- A Google Objective-C “style guide”
- Geometry libraries to manipulate NSRect, NSPoint, and similar.
- Gradient-based shading code
- Additions to NSBezierPath, including GCPath conversions, round rects, and shading
- Login item manipulation (Mac specific)
- gzip for NSData
- XCode configurations
- and.. a lot more, naturally.
Google promises that more tools and updates will come along soon. Enjoy!
P.S. We need your help! As an aside, we are planning to run a feature soon on XCode customization and configuration. If you have any XCode configuration or customization tips or advice, please get in touch with us or leave your ideas as a comment on this post! We will give you credit, of course.
(Thanks to MacResearch.org for analysis.)
Does anyone have a nice Objective C beautifier, preferably integrated with Xcode, that applies these rules?
This is useful stuff, but it isn’t news; GTM has been available for quite a while (over a year? I started using it about a year ago.)
I would take the style guide with a grain of salt. Google is infamously anal about exact adherence to specific coding styles, right down to where you must or can’t put spaces, and some aspects of this guide — especially the 2-char indents — conflict with the way nearly everyone else write Obj-C.
Jens – I agree fully with you. To be candid, I’m a bit surprised to see some of the stylistic guidelines appear as “best practice” recommendations. Not to continually single character indentations but our teams prefer the use of tabs over spaces due to conflicting preferences over a wide audience of software engineers (i.e. some prefer two char indentations, some four, and some five).
Additionally, structured exception handling is key for us especially in larger layered designs. I disagree with Google’ recommendation to not @throw exceptions except from framework-level code (or libraries), which arguably is a great setting for @throw/@catch/@finally semantics (since you don’t know whether you’re part of a larger orchestration). However, BOOL is not a replacement for @throw in non-framework-level code and for the same reasons.
Also, I’m certainly not a fan of suffixed member-level naming schemes. Again, these are Google’s recommendations and not Apple’s.
Obviously, there are other recommendations that are IMHO “good” such as ensuring proper scoping modifiers are in place. All this said, it’s great to see Google putting effort into Objective-C.