As with most things in life, there are two opposing schools of thought when it comes to software. When it comes to the size of things you can either go big or small. Is your app going to have a large scope or small scope? Is it going to target the general market or a particular niche?

When I started work on Code Collector Pro 1.4 over the weekend I was confronted by the issue of whether to go big or small on two key points: the size of updates I release and the size of the classes I write. These are key decisions that affect all the software we write, so it is worth deliberating over them. Now these aren't questions I've only just asked, they are ones I've looked at continuously and am only just starting to set myself on.

Release sizes

There are two extremes to software release size. At the large end of the scale are products like Adobe Creative Suite, Microsoft Office and Apple's iWork and iLife suites. They have a release roughly every 1-3 years and they feature large updates to several applications. At the smaller end of the scale are products like WebKit or Adium, where small releases are made every day in the form of nightly builds.

Most Mac devs go for the middle ground of this, releasing several medium sized updates a year, though what constitutes a "medium sized" update varies widely. I've been striving to reach the smaller end of the scale with little success until now. The combination of full time education limiting coding time, and a lack of discipline when building releases has led to a series of sporadic releases that are quite large.

With Code Collector Pro 1.4 there was a long list of features building up. There hasn't been a release for 14 months and the featured planned involved would take a good 3-4 months to complete. The release eventually included a UI overhaul, new sharing features, syncing and a re-written syntax highlighting engine.

So I opted to break it up into smaller releases. The UI overhaul is a collection of many small changes and some under the hood changes and nicely separates into a different release. Sharing improvements and syncing were the two major features I wanted for 1.4, so these would fit nicely into a second release. And the syntax highlighting improvements would also fit nicely into a small release. As such the large 1.4 now became much smaller versions 1.4, 1.5 and 1.6.

The current plan is to work on 1.5 straight after releasing 1.4. But why not then combine them? Well there are 3 main reasons not to:

• Syncing and sharing will take 1-2 months to implement, but the UI improvements can be done in a few weeks. As they are the low hanging fruit I would most likely do them first. So why have those improvement sitting around on my computer for a few months when I could ship them to users?
• Smaller releases often lead to a better feeling of productivity. You do have more time taken up by prepping for release, but you feel like you are getting somewhere much faster. It's easier to climb up a set of stairs than a cliff face.
• Releases = money. Whenever you make a release people see it on download sites and news sites. This leads to people downloading the app and then ultimately buying it. The more people buying your software the more people spreading word of mouth advertising and the more sales you get. Ultimately each release is an extra boost of energy into a positive cycle.

Class Size

For those of you who aren't programmers a brief explanation. A class is a unit of code. It contains data and actions upon that data. While not always true, generally a class = a separate file of code. As with release sizes you can either have a few large classes or lot of small classes. Cocoa provides ways to help you divide your code up. Code relating to windows goes into Window Controller classes, code relating to any documents goes into your Document class.

Prior to OS X 10.5 there was a missing piece of the puzzle though. While you could easily split up your application into windows, it was harder to split up these windows into individual views. Then in 10.5 Apple introduced NSViewController, which made this task easy. This means you can split your UI up into even small classes, which leads to easier to maintain code and more reusable code.

As an example, these are the window and view controllers that make up a typical screen in Minim:

As you can see, this one screen has 4 main components. The window, which contains a sidebar and an info panel, the latter of which contains the current tab. Each of these is coded in a separate file. This means that if I need to edit something to do with the sidebar I open the sidebar view controller's file. It also makes things more re-usable. There is a file that contains the file manager view controller class. This same class is used for songs, podcasts, albums and shows.

Now Minim is build with Leopard in mind. Code Collector Pro however is very much a Tiger era application in its design. This is what Code Collector Pro's main window looks like from a class point of view:

There is one class that manages the window, the sidebar, the snippets list and the code view. It even controls the inspector panel. At 2420 lines long it is the second biggest class in any M Cubed app, beaten only by the class that talks to Lighthouse in Lighthouse Keeper. That over 3 times the size of the biggest class in Minim.

Now while a large class isn't necessarily a bad thing, a large class that does lots of different things is. If I want to edit something to do with the sidebar in CCP I've got to search through 2400 lines of code to find what lines are relevant, compared to Minim where I open a file where all the lines are relevant.

I'm currently working through the process of breaking up this monolithic class into much smaller, more manageable chunks. I've already managed to split it into 7 classes, I may be able to divide those even further. Ultimately though, this will add nothing new to the application. It will work exactly the same as it did before. What it does do is make it easier to add new stuff in the future.

It's How You Use It

So does size matter? Well as the title of the post suggests, it does. But what is a good size depends on many things. To quote Albert Einstein, "Everything should be made as simple as possible, but not one bit simpler". You should strive to make things as small as you can, but not unnecessarily. While I can break one large class up quite easily, another may not break up. It may be the case that it is already as small as it needs to be.

The same goes for releases. I can split up what was going to be CCP 1.4 into 3 different versions quite easily, they logically split up. However, Minim 2.0 couldn't have been split up. It was a large project, but it couldn't have been made any smaller. Everything has its size, the job of anyone creating something, be it a piece of code, a product or a business, is to find the right size.

Comments (3)

---

One of the perennial topics in the Mac developer community is that on whether dot syntax is a good idea. Reading through blog posts and twitter feeds an unfamiliar observer would deduce there that this is a Marmite issue: you either love it or hate it.

The problem is a lot of people familiar with the topic also see it as that, but the truth is quite different and there are some subtleties in the argument, particularly the dislike camp of which I am a member, that are often over looked. I'm hoping this blog post will give a better idea of why people, or at least I, dislike dot syntax.

History/Programming Lesson

For those unfamiliar with it (or those who don't program) I'll give a brief history and overview of the technology that causes the problem. Feel free to skip this section if you are already familiar with this tale.

In object oriented programming (OOP) you store variables (containers for data) within classes (containers for variables and methods, or actions upon that data). One of the key concepts is encapsulation, which means that these classes are black boxes and you cannot directly access the variable, but instead have to call a method to get to the data. Think of this as a bit like a cash machine, where you don't directly get the money, but instead use an interface to ask for the money and then receive it. These sorts of methods go under many names: accessors, getters and setters, properties etc.

In versions of Mac OS X prior to 10.5 writing these methods required writing a lot of code that is almost identical for each variable. For example, the code for accessing the variable foo would be:

//Header
- (id)foo;
- (void)setFoo:(id)newFoo;

//Implementation
- (id)foo {
    return foo;
}

- (void)setFoo:(id)newFoo {
    if (foo != newFoo) {
        [foo release];
        foo = [newFoo retain];
    }
}

There are many variations on these methods but they all do the same thing, either return the contents of a variable, or replace the contents with a new piece of data.

You can probably tell that writing that over and over can get tedious, when there are only minor differences you can make, usually in memory management or thread safety. So in Mac OS X 10.5, Apple introduced Objective-C 2.0 which featured, amongst other things, properties. This allowed the simplification of the above code to:

//Header
@property (retain) id foo;

//Implementation
@synthesize foo;

Much simpler. It also adds extra information that wasn't previously there, such as the type of memory management used and whether it is thread safe or not.

Now while this brought almost universal praise, Apple also introduced a new syntax for accessing these properties: dot syntax. This allowed programmers to use properties in a different way:

//Standard way
variable = [object foo];
[object setFoo:variable];

//Dot syntax way
variable = object.foo
object.foo = variable

Implementation vs Idea

For the purpose of explaining why people feel a certain way about dot syntax in Objective-C it is important to distinguish between implementation and idea. In this case, dot syntax is the implementation. The idea is a simpler way to use properties. A lot of the complaints are not with the idea, but with the implementation.

Another example of this in Objective-C 2.0 is garbage collection (automatic memory management). There are a lot of people who are wary of using garbage collection. Some are wary because they are used to the idea that garbage collectors are much slower and less efficient than manual memory management (in most cases the opposite is true with the Objective-C garbage collector), but this stigma of the idea of garbage collection remains.

Then there are people who are wary of the implementation. They feel that it is a major commitment to something that is relatively untested. I had a discussion a few days ago where a programmer started writing a garbage collected app and then found a bug with no work around other than "wait until Apple fixes it", so he had to go back through his code and switch to manual memory management.

In this case this is a complex piece of technology that is quite new and can seriously harm your project's shipping date if you encounter a bug with no work around. Now before people get the idea that I'm anti-garbage collection, I'm not. I'm using it in Minim 2.0, but this is only because it has been around for 2 years now, and many bugs have been fixed in updates to OS X 10.5. The garbage collector in Objective-C is great, it is just a 1.0 release.

Anyway, enough with the small detour into garbage collection, that isn't the main topic of this post. However, it has offered us a good example of why someone may dislike an implementation, one that is different to why most developers dislike dot syntax. Developers are wary of garbage collection because it is new. Developers dislike dot syntax because they believe it is flawed.

Why Dot Syntax?

There are many reasons one can suggest for why Apple chose dot syntax. The most obvious is that it is somewhat similar to how other languages work. Whereas Objective-C uses [object method] to run a piece of code, lots of other languages use object.method(), and some even allow identical object.property = newvalue syntax for variable access.

It is this familiarity that may help programmers move from other languages. Unfortunately this isn't necessarily the case. Dot syntax is inconsistent, working for methods that aren't properties. It also can cause confusion between objects and C structs (more on this later). I have seen several new programmers get confused by this, as they can use dot syntax for certain methods, but not for others. There are even pro-dot syntax developers who agree that it shouldn't necessarily be taught to new Objective-C programmers until they have got a good grasp of the language.

Now there is an argument against those of us who are anti-dot syntax, that we are simply Objective-C old hands who are opposed to change. This isn't the case. There are many people who have been using Objective-C since before Apple had anything to do with it who are using dot syntax and there are those who only started with it a few years before dot syntax arrived that dislike it. I only started programming in Objective-C 5 years ago, not exactly an old hand when you consider Objective-C is over 20 years old.

The other reason why this isn't true is that these programmers embrace all the other changes. They use properties and fast enumeration and garbage collection. They use new APIs and new tools. A lot of these "luddites" who are supposedly opposed to change are actually the ones at the forefront of change. The difference is that change can be for the worse or for the better, and while they believe most of Objective-C 2.0 is change for the better, dot syntax is change for the worse.

State vs Action

Now one argument for the idea of a separate syntax for property access is that it helps separate state and action. This is quite useful in places as you can tell when state will change, which is useful for many things, but importantly thread safety. For the most part I agree with this, but I believe there are issues.

The biggest is simply an issue of how you conceptually view your program working. Those who are fully behind the state vs action system see [object doSomething] and object.property as different things. One is performing an action, one is accessing state. I see things at a more abstract level, where both those are simply sending a message to an object, so they are identical in what they do. This is somewhat anal, but it is how quite a few developers feel.

Structs

I made a tweet that proved to be quite controversial, saying that I thought developers who think dot syntax is a good idea don't do much UI coding. The reason behind this idea is that UI coding requires the usage of C structs. A struct is a simple container for several pieces of data, and in some ways is a sort of lightweight class. It is because it is lightweight that it is used all over the UI side of Cocoa for defining rectangles, sizes and points.

So what is the issue? Well this is how you access a struct:

variable = struct.field;
struct.field = variable;

Looks familiar, doesn't it? This is the biggest issue, the fact that struct and property access is identical. If you look at the following, would you be able to tell me which is the struct and which is the property?

a.b = foo;
c.d = bar;

Of course that example is a bit contrived so let us look at something that you may actually find in Cocoa:

rect = controller.view.frame;
rect.size.x = 10;
controller.view.frame = rect;

Now an experienced Cocoa developer could tell you that controller and view are objects and rect and size are structs, but someone new to Cocoa couldn't tell the difference.

Of course we could just get rid of structs and use objects for everything, couldn't we? Unfortunately no. Structs are relatively lightweight when compared to objects, so are ideal for tasks such as defining a rectangle when you only need to collect 4 values into 1. You don't need all the unnecessary cruft of creating an object, so it makes your code faster and your memory usage smaller (granted these aren't as big an issue with modern computers, but there is no point slowing things down).

The other issue is that Objective-C is also C. Anything valid in C is valid in Objective-C, and structs are part of C. There is no getting rid of them. You could get rid of them from Cocoa, but you would still be mixing object.property with struct.field.

Of course this confusion can potentially be dangerous. struct.field is simple memory access/assignment, you cannot make it do more. However, object.property isn't necessarily just memory access/assignment (technically it almost never is). There could be file access, network access etc. happening under the hood, but you see the same thing. This confusion can be potentially damaging.

[UPDATE] Note, that while I mention object.property, I don't imply that accessor methods will be doing resource intensive tasks, but the fact that dot syntax isn't limited just to properties means that object.method could be used and would be computationally intensive.

Conclusion

So what is the solution. Well as I said earlier, most developers don't have an issue with the idea of a different syntax for property access, the issue is with the implementation. The solution would have been to not overload the . character. There are many other ways that property access could have been done and most of the arguments above vanish if a different character is used. Why not foo~bar, foo•bar or foo@bar. None of those characters are used in binary operations in C or Objective-C.

The important point is, those who are against dot syntax aren't simply the old school who don't like change. They like change, they embrace change, but they just feel this is a change for the worse. You may feel differently about the syntax, but there are many significant cons to the current implementation, which is why there will always be those who dislike it. And all of those cons revolve around one character.

Comments (8)

---

One of the first things you'll see when you open a new project in Xcode is this:

This is the default Xcode source list and to be frank, it is one of the biggest pile of donkey droppings Apple has created. One table is used to manage files, built targets for each bundle, access executables for changing sessions and also get access to compiler errors, searches, project bookmarks, version control, breakpoints etc. Needless to say it is a frustrating and annoying experience.

The problem is, this has been solved in the condensed layout mode, with the items split up into 3 different tabs. File management is done in the Files tab, target related stuff in the Targets tab and all the other guff is thrown into the Other tab. Apple obviously acknowledges that these need to be separate, but only provides an obvious way to do it in one of Xcode's 3 layout modes. For any project with a lot of files you need to do a lot of scrolling to get to other sections.

The key word there is "obvious". I discovered yesterday that there is a way to make the Xcode source list suck a hell of a lot less. I've known for a while that you can split the source list vertically, but what I didn't realise is that each split view can have different items in it. This opens up the source list to be a much more flexible tool.

With this new discovery I have been able to add all the bits I care about to different split views and delete all the other stuff I don't care about. I've never really used anything other than the project, targets and executables sections. The others generally can be accessed from elsewhere in the UI, but in an All-in-one layout the breakpoints group can be useful as it prevents the breakpoints UI from popping up in a separate window.

So now my source list looks like the one below (though less condensed as I'm not trying to take screenshots of it most of the time). The top files section takes up most of the space as that is where I spend most of the time. I've moved the NIBs smart group into a section of its own so I can always have access to my NIB files no matter what the state of my file tree is, and I've got the 3 other important sections at the bottom, which I can move up as and when I need to access them:

But how do you show and hide these various sections? Well the quickest and easiest way is to just select an item and hit backspace to delete it. The other way is to right click on an item, select the preferences menu item and select the item from the list to remove. Unfortunately this is a little buggy so do not combine the two methods. The menus don't want to link up to the correct split view which can cause a lot of frustration after deleting by hitting backspace. As always, I've filed a bug which you can read on Open Radar.

It would help to get Apple to fix this (hopefully for Xcode 3.2) if others were to file bugs referencing this and show it is affecting a lot of people. The fact that the menus are so buggy with this shows that this probably isn't a well known tip, I've used Xcode for nearly 5 years and only just found this, but hopefully it helps you with making Xcode's source list much more useful.

Comments (3)

---

So I’ve started to do a lot more unit tests than I usually do while working on Minim 2.0. I’m not doing test driven development, I made my thoughts on that clear in an earlier post. However, I feel a lot of the issues people have with unit tests and their use are misplaced. So I thought I’d outline where and why I’m writing unit tests. There are a few rules I have about whether a method should or should not have unit tests.

Trivial methods don’t need tests

If you are unit testing properties you are insane. If you are unit testing methods with one or two lines you are insane. There is no need to test these methods. You can understand how they work quickly and easily and if you don’t because these few lines are very complicated then you need to break your code up into a few more lines.

Methods with complex logic need multiple tests

Any methods that have complex logic should have multiple unit tests. The reason is that complex logic is not as easy to understand at a glance, even if you wrote it. As such it is much easier to break. There are very mixed opinions about using automated tests to help develop an app, but almost everyone can agree that automated tests are great if they stop you breaking good code.

Depending on the complexity of the method you should have multiple tests. Obviously you can’t test everything but try to cover the most common case and any edge cases you think could cause problems. For example, if your method should do something differently depending on whether a flag is YES or NO then test both the YES and NO cases.

Methods used by multiple parts of the app need tests

These are possibly the most important methods to test. These are the ones that are accessed by multiple parts of your app so you will likely be changing quite often. The problem is that while you change it for one part of your application, you may forget to test all the other parts of your application that use it so it is good to make sure that these other parts get what they expect from the method.

If you fix a bug in a method then write a test for it

What is the point in fixing a buggy method if you’re just going to break it again later? Write tests when you fix a bug to make sure it stays working. This method also means your test suite can grow organically.

These 4 rules are what I use to decide whether I should write a test or not. Often I’ll work on a feature and get it working and then go through my methods and decide what would be worthwhile writing tests for. This way I can focus on development and then spend a few hours afterwards concentrating on the testing. The added benefit is that I can think again about how my code works, which may lead me to find issues that a unit tests can’t fix.

Comments (2)

---

Page 2 of 2 pages  <  1 2