Open source style checker for Objective C

I'm curious why this was written as a checker instead of something that actually fixed the problems instead of whining at a human to do so?

Automation to me is the editor making it all right with minimal human thought or micro-management. For Eclipse and Java, it has a Format Source menu as well as being able to trigger that on a save, so it all just works.

With Objective C, Xcode is no help beyond some crude indenting. I bought a copy of Jetbrains' AppCode with their similar source formatting functionality being a major reason. The usual tools like indent don't support Objective C, and the two free tools I found were far too painful.

You are still reinventing the wheel :-) : http://clang.llvm.org/docs/ClangFormat.html

Uncrustify is also fairly complicated and produces some very strange unexpected indentation behavior sometimes.

I'm fairly new to iPhone dev and was very surprised when I ran into this. Is there any reason it doesn't?

Given that context switching is one of the core costs of day to day software development, it's hard to overstate how valuable it is to have code across the code base feel "familiar". Little details add up to make a bigger difference than you might expect. I'm not alone in feeling this way - take a look at Google's extensive programming style guidelines some time.

https://code.google.com/p/google-styleguide/

Of course, the better answer (and we'll build it at some point) is something like gofmt so that you don't have to worry about this stuff at all.

Tools such as this one shouldn't bother to check. They should just fix the issues and shut up.

I'll happily go out on a limb even further than you: enforcing consistent formatting like this IS a waste of time. It's just pointless makework, and buys you practically nothing relative to the amount of effort required. And it doesn't even have to get to this level, before it's needless; 99.9% of programmers out there format their code in one of about 3 or 4 relatively consistent and non-insane fashions, and it causes no problems to just have them mixed and matched about the codebase. People may complain a bit, but you can ignore them; the issue is not as significant as it might seem. Out of all the problems you can encounter when working on a large project in C/C++/Objective-C - and if I haven't actually seen all of them, I've seen enough that I think I know what to expect - consistent code formatting is seriously the least of them.

But I rail against enforcing code styles with a checker because the cost outweighs the minor benefit. But if there were a quick way of making all the code look the same automatically, such as an automatic reformatting tool, then it wouldn't matter. Something cheap doesn't have to provide much benefit in order to represent value for money.

As an example, Visual Studio does a good job of fixing formatting, at least if you're working in C#. (It may be the same for VB.NET. It isn't for C++.) You can enter something pretty much any way you want, then press Ctrl+K, Ctrl+D, and it will reformat the document according to your style preferences. And Visual Studio will reformat things anyway when you type the } that closes a scope, or when you paste some code in, so generally things get formatted as you work anyway.

And, unlike its C++ support, with C#, it doesn't just piss about by changing spaces into tabs and aligning the curly brackets and fixing up the indentation. It actually dives right in there and puts spaces in your expression. Sometimes it will even insert and remove new lines.

Type in this:

    int[]x=new int[]{1,2,3,x+f(x)};

and after reformatting, it will look more like this:

    int[] x = new int[] {1, 2, 3, x + f(x)};

(As usual with Visual Studio, they did a reasonable job, and then appeared to give up before they'd thought things through. As far as I've ever been able to tell, the style preferences are local per-user, rather than associated with the file's container, or stored, emacs/vim-style, in the file itself, so per-project style preferences are out. But you can probably assume that most people stick with the defaults, which indeed they seem to, and so most code still ends up looking pretty much the same.)

If you want to get your team singing from the same hymn sheet, get them forming their names the same way, using (or not) exceptions the same way, using consistent strategies for particular problems, using/not using STL/const/MI, etc. - that sort of thing. You'll fix way more problems from simply discussing this a bit before you start than you will from a whole year's-worth of making sure there is exactly 1 space after every opening bracket.

If "most cases" means the average small team (2-3 developers), then you probably have a point. Once you have more than that, I think it's absolutely necessary to enforce code style in this way.