8 ms·
Seven Deadly Sins of Modern Objective-C
- jensnockert 14y agoPoint 5 seems like dangerous advice, shortening types (especially floating-point types) without analysis isn't a good idea and especially not a deadly sin. Changing doubles to floats can give a significant performance boost (mainly on ARM with Neon) but it brings significant limitations on range and accuracy that can lead to subtle bugs if you don't do the analysis (especially if you mostly test it with double precision.)
- stephencanon 14y agoVery much this. Using floating-point types that have different sizes on different platforms without detailed analysis of the algorithm is a recipe for hard-to-diagnose bugs. Use float, or use double, whichever is most appropriate. There are some subtle historical reasons why CGFloat is defined the way it is; a reasonable argument could be made that it "should have" been double on all platforms with 20/20 hindsight, but it can't be changed now without breaking binary compatibility.
- RyanZAG 14y agoRegarding the comments on TDD - the important part of TDD is not the unit tests. The important word in 'Test Driven Development' is the 'Driven'. You can actually do TDD without any kind of automated testing, by defining user tests up front in English, and then manually testing these when hitting milestones. The automated unit tests just make this process more streamlined, but are very much not the key aspect of TDD.
- revscat 14y ago... and are prone to human error. While you could do manual tests before every check-in, this is prone to error to the point that I would not trust it. For any a project of any significant size such a thing would inevitably lead either to steps being missed or the entire thing being skipped altogether.
- RyanZAG 14y ago100%. Automated tests are far superior to manual. The point, however, is that TDD is not the same thing as unit tests. Too many people add some unit tests to their code and then claim they are doing TDD. Too many people try to do TDD by having 100% unit test coverage. It's very important to get the two concepts straight.
- taligent 14y agoAutomated tests are only superior when it is too intensive to do manually e.g. integration tests or serialization tests. But otherwise especially for iPhone apps manual testing is far, far superior. It will always pick up issues with the UI that automated testing never will. And the UI issues are the most important ones.
- deleted 14y ago[deleted]
- eddieroger 14y agoOh man, am I guilty of not using dot syntax consistently. I actually try not to use it because it is so out of place with the rest of the code, but it's a leftover habit from other languages, and old habits die hard.
- mikeash 14y agoI would argue that never using it counts as "consistently", as long as this isn't in dire conflict with the parts of the code that other people wrote.
- bitwize 14y agoObjective-C dot syntax is fucktarded. The dot is a structure-member indicator; why are you using it on a value of pointer type? The thing is, Smalltalk has a perfectly good getter/setter convention that's almost as compact and straightforward: for a property called 'foo' the getter is called 'foo' and the setter is called 'foo:' (takes one arg). Apple could have used this convention in its method synthesizer (they opted to make the setter the somewhat more awkward 'setFoo:') and everybody would be clear on what was a struct member access and what was a message sent to an object. But no.
- skylan_q 14y agoI'd say #1 isn't an Objective-C issue, but a Cocoa issue. Do not tarnish the wonderful language with the terrible framework. :)
- camus 14y agoI thought Cocoa was pretty good, what makes you think it is terrible ?
- myko 14y agoSame here. I think without Cocoa I wouldn't like Objective-C much at all.
- borgopants 14y agoCocoa is pretty good, but like all frameworks, it definitely has its downsides. Point #1, unfortunately, seems to be something that the author has a hangup about. I find that using a single XIB for a view controller at a time works the best for me, and maintains some semblance of MVC. I work on a relatively large app, with more screens than usual, and I never find it hard to figure out view controller transitions or anything like that.
- rimantas 14y agoI think it is worth mentioning that there is Cocoa and there is Cocoa Touch: supposedly saner and cleaner version. I am only familiar with the Cocoa Touch so I cannot compare myself.
- hockeybias 14y agoActually, deadly sin No. 1 should be 'Using Objective-C'... Ugh. What a mess.
- bennyg 14y agoI hate Storyboards - I can't even come close to manipulating views/subviews the way I want to with them. I love dot syntax. Writing myArray.count is a lot easier than [myArray count] and then when messages start getting nested it bothers me visually - ie [[myView subviews] count]. Of course, I love messages and the syntax used for calling functions too. Objective-C is my first real language though, so what do I know.
- andymoe 14y agoI have to say I very much prefer [myArray count] to myArray.count since I think of it as a method instead of a property though I agree using dot syntax for synthesized class properties is preferable.
- thelarry 14y agoHow _do_ you use story boards? In the newer xcode I always opt out. Seems to be too general to make it do what I want
- wyuenho 14y agoPoint 6 is a rather uninformed opinion. The reason the Keychain and Sandbox API are written in C is because they are designed to be used straight up by C programs without calling in obscure Obj-C land. Have you ever wondered why Mercurial and Subversion are able to put your credentials in Keychain? This is why. Lower-level, general purpose Mac OS APIs have always been written in C, and they should.
- mikeash 14y agoHe calls out CoreFoundation as an example of doing it right, though. I don't think he means that the problem is C APIs in general, but bad ones.
- Aqua_Geek 14y agoI agree with you, but there really should be a nice, easy-to-use wrapper written in Obj-C as well.
- sarah2079 14y agohttp://developer.apple.com/library/ios/#samplecode/GenericKeychain/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007797-Intro-DontLinkElementID_2 http://developer.apple.com/library/ios/#samplecode/GenericKe...
- chrisballinger 14y agoI switched to SSKeychain (https://github.com/soffes/sskeychain https://github.com/soffes/sskeychain) after using SFHFKeychainUtils for a while because I think it's cleaner and more regularly updated.
- Aqua_Geek 14y agoSame here. SSKeychain is pretty well done, but it only has support for passwords/accounts.
- alayne 14y agoOld style properties vs. auto synthesized properties vs. ivars are good for some entertainment as well.
- primitur 14y agoI always ask myself why I'm thinking about these things in the first place. Its a failure of the language, in my opinion, a deep design flaw that isn't being recognized. Why do things need to be synthesized in this day and age. I know why technologically, but it doesn't have any actual use in real life. Its just window dressing and something special the developer needs to think about, with no real solid gain other than to entrench a platform-specific methodology into the language, and thus ensure developer mindshare is captured and maintained ..
- angersock 14y agoIs there any compelling reason that we know of for Apple using Objective-C in their development tools? In all seriousness, as a programming language, what does it bring to the table that C, C++, or some scripting language do not? (I ask this in good faith--not trying to troll. I am genuinely curious.)
- kryptiskt 14y agoBoring answer: NextStep bet on Objective-C and OSX is built on that, and iOS is derived from OSX.
- chc 14y agoAmazing that this isn't voted higher. Regardless of Objective-C's virtues, this the real reason. The decision was made back in the late '80s for NeXTStep, and it just hasn't been changed since then. Apple was kinda moving toward Java in the early days of Mac OS X — WebObjects was ported to it, and it was a peer language for Cocoa up to Mac OS X 10.4 or something — but Mac users hated Java, as it was dog slow at the time, so Objective-C won by inertia.
- asolove 14y agoObjective-C has the dynamic properties of a language like Smalltalk, but you can also drop down to C and write fast imperative code. Besides the raw capabilities of the language, the community of Objective-C developers fit very well with the language. Where Ruby would use an abbreviation, ObjC prefers long explicit names. And the interleaved method name/arguments makes the code readable in a very specific and refined aesthetic. It isn't obvious to everyone, and it isn't a natural way to write some kinds of programs. But for writing fast and highly-interactive UIs, it remains a high water mark. The best advice is: try going through one of the books by Aaron Hillegass to get a sense of the serenity of writing proper Objective-C/Cocoa code.
- wonderzombie 14y agoLook up Smalltalk for some hints. I'm not an expert on Obj-C or Smalltalk but Obj-C borrowed pretty heavily in some respects, as I understand it. It is object-oriented, but it is a substantially different paradigm from the C++/Java family. As another hint, Ruby was pretty heavily influenced by Smalltalk as well. Think about stuff like responds_to? and whatnot, where you're sending messages to objects and objects can actually intercept and react to those messages. The comparison to C++ is pretty illustrative, if only as a point of contrast; C++ is certainly not the only possible approach to OO in a C-like language. Alan Kay, the guy who did Smalltalk and OO, doesn't particularly approve of the C++ approach to OO. In practical terms, though, I think it's somewhat historical, to the extent that any programming language's usage is or is not historical. :)
- oliland 14y agoUnit testing (and by extension, TDD) is easy in Objective C: Just test your models. Your models are (should be) the only thing that makes your app unique.
- bitwize 14y agoObjective-C isn't just for iOS and it isn't just for OS X: the language, and the runtime, is built for both. Is he aware that Objective-C can be used on non-Apple platforms?
- frankus 14y agoWRT point 3: Xcode will now allow dot-syntax access to non-property getter methods, however its arguably clearer to use dot syntax only for properties since they're declared and documented separately from old-style getter methods. There's also a slippery slope argument, since something like myMutableArray.removeAllObjects will compile (albeit with a warning).