#Objc and swift share c string code#

Thanks to Optionals we now have the “nothing-value” completely defined, we just need to add a question mark after the data type. How many times, working with functions that return “a value” or “nothing”, did you wonder what the best way to define “nothing” was? I’ve used NSNotFound, -1, 0, custom return values… We’ll end up enhancing readability and saving some keyboard typing.

We are not required to adopt type inference or to remove semicolons and parentheses but we can consider these choices as the suggested ways to write code in Swift. In variable binding, for example, we can’t use parenthesis: They are no longer required.īut remember, what we write between the parenthesis is evaluated as an expression and we are not always allowed to write it that way. We should try to use consistent methods naming, otherwise it would be difficult for another developer (and for you) to guess the type inferred by an unfortunate naming choice:Īnother big change is the use of parenthesis. This is another convenience that turns out to be a bit hard to embrace, when coming from a verbose language like Objective-C. Type inference is the ability to assign a type to a variable, inferring it directly from its definition. My life is better now (and now I forget to add semicolons in Objective-C :|) Look at these 2 rows of code and find the differences:ĭuring the first 2 weeks of training with Swift I forced myself to remove semicolons from the end of each line of my code. You’ll end up using more constants than you’d expect. So just keep an eye on it and try to figure out the effective role of your variables.

With Swift, Apple suggest developers to give some more thought to the choice of using a constant ( let) instead of a variable ( var). In Objective-C I’ve rarely used the const keyword, even when I knew that some data would never change (OK… shame on me). My suggestion is to wait for visibility modifiers (Apple is working on it) and in the meanwhile just use good documentation with or without extensions. The question is: is this weird pattern worth the final goal of partially hiding the private elements? The private elements are not really hidden but to access them we have to go through the “private” constant. We put private implementations into the private constant instance and we use the “regular” class implementation just as public interface. For example, we can move the elements we want to be “public” at the top of our file, maybe using an extension just to separate public and private areas.Īnother really common choice is to prefix private methods and variables with an underscore “_”.Īlthough we can’t modify the visibility of our class elements, we can try to make accessing some of them “more difficult”.Īn exotic solution that partially hides private area (at least to the autocomplete) can be achieved using a nested class, here’s an example: We can easily enhance readability of our classes with good documentation. The first is obvious: Using common sense. There are some caveats that we can use if we really are unable to tolerate this huge change:

We just implement our class (and at the time of writing it is not even possible to add visibility modifiers). In Swift interface and implementation aren’t split in two files. I have to admit that I’m a strong supporter of that model Obtaining and sharing information about a class just via the interface file is safe and quick. Single file vs Interface-Implementation filesĪ first big change that is worth mentioning is the dismissal of the interface.h/implementation.m structure. NOTE: this article has been written referring to Beta 2 of Xcode 6. So without further ado let’s dive into the core of the article! I’ll try to give you hints and I’ll discuss the main pitfalls, trying to compare, when possible, the different approaches of these two languages.

In this article I want to share with you some of the thoughts I had along the way during my transition from Objective-C to Swift.

#Objc and swift share c string code#