

Open source style checker for Objective C - rwalker
https://github.com/Cue/ocstyle

======
rwalker
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](http://www.opengroove.org/parcon/parcon-tutorial.html))

~~~
rogerbinns
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.

------
zbowling
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
You are still reinventing the wheel :-) :
[http://clang.llvm.org/docs/ClangFormat.html](http://clang.llvm.org/docs/ClangFormat.html)

------
Zev
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](http://uncrustify.sourceforge.net)

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

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

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

------
bla2
Or use a tool that fixes your style instead of just listing errors:
[http://clang.llvm.org/docs/ClangFormat.html](http://clang.llvm.org/docs/ClangFormat.html)

------
jgh
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.

~~~
to3m
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.

~~~
rwalker
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.)

------
marksands07
clang-format exists to do the same thing
[http://clang.llvm.org/docs/ClangFormat.html](http://clang.llvm.org/docs/ClangFormat.html)

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

