Open source style checker for Objective C

by rwalker • 13 years ago

35 16 13 years ago

rwalker3• 13 years ago

I'm a big believer in automating process where possible - instead of trying to remember style rules or dealing with inconsistent code across a codebase, just write a script to deal with it!

This one was particularly fun to write because it was an excuse to use the awesome parcon library (http://www.opengroove.org/parcon/parcon-tutorial.html)

rogerbinns• 13 years ago

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.

jgh• 13 years ago

While I can appreciate style guidelines for code, I can't help but feel like this level of pedantry is excessive and probably a total waste of time in most cases.

rwalker3• 13 years ago

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.

to3m• 13 years ago

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.

rwalker3• 13 years ago

Completely agree that reformat beats style checking. I think reformat also subsumes style checking from a code complexity perspective, so consider this a step on that path. Launch and iterate.

As for the rest of your comment: we've been using this thing for 9 months. It has made us more productive. It's made it easier to onboard new people in to the code base. It doesn't cost much - you pretty quickly stop seeing errors as you get used to the conventions. By letting a script worry about these admittedly less important details we have MORE time to talk about exceptions, libraries, locking, etc.

So, while in theory much of your comment sounds true, I can state very conclusively that in practice it hasn't happened the way you suggest.

(Also, naming conventions and documentation are important things enforced by the script. Maybe you didn't see part? I'll make it clearer in the README.)

asarazan• 13 years ago

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.

zbowling• 13 years ago

Been doing something like this but instead of a custom parser, I've been building it against clang's own AST instead of reinventing the wheel.

Someone• 13 years ago

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

Zev• 13 years ago

Neat. Playing with parsers is fun!

FWIW, a similar tool exists that works with most C-style languages, `uncrustify`. Might be worth looking into as well?

http://uncrustify.sourceforge.net

HaloZero• 13 years ago

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

revetkn• 13 years ago

This reminds me that it's 2013 and Xcode still doesn't have a built-in code formatter :(

stusmall• 13 years ago

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

bla2• 13 years ago

Or use a tool that fixes your style instead of just listing errors: http://clang.llvm.org/docs/ClangFormat.html

marksands07• 13 years ago

clang-format exists to do the same thing http://clang.llvm.org/docs/ClangFormat.html

natch• 13 years ago

$ pip install ocstyle -bash: pip: command not found

Open source style checker for Objective C

Related Stories