
ObjClean - jawngee
http://objclean.com/index.html
======
LinaLauneBaer
I am programming Objective-C for over 10 years now. Alone and together with
other people.

My co-founder is also a long-term Objective-C developer and we have different
"styles" of programming. When I write code I care about style but only to a
certain extend. When I edit my co-founder's source code I simply adopt to his
style and that's it. No need to "formalize" anything as long as no really dumb
code formatting rule is used that has real technical drawbacks like:

    
    
        if(expr)
            doThisOneLinerWithoutCurlyBraces();
    

I worry much more about the architecture, correctness and good names for
things these days...

A tool like this certainly has its benefits though. Depending on how
experienced your team is you want to give junior developers automated
guidance.

What would be really cool though is if the formatting rules were applied by
Xcode itself. Then each team member could have individual coding style
settings. Before pushing to git a "company wide" rule would be applied. This
has drawbacks as well: gif giff becomes less useful for sharing between co
workers, debugging information is out of sync...

~~~
asveikau
Not sure what the "technical drawbacks" are, unless
doThisOneLinerWithoutCurlyBraces is a macro and the author didn't think to do
the do { } while (0) trick. The Linux kernel coding style actually advocates
this style:
[http://lxr.linux.no/linux+v3.12.6/Documentation/CodingStyle](http://lxr.linux.no/linux+v3.12.6/Documentation/CodingStyle)
(line 157, "Do not unnecessarily use braces where a single statement will
do.")

I agree with what you're saying though. Making whitespace differences into a
build break seems to miss the point a bit. Is that what the author thinks
"clean code" means? Consistent whitespace and nothing more? Consistent
whitespace is certainly a good idea but there's so much more to a sane code
base than how many newlines follow a declaration or whatever.

~~~
reginaldjcooper
Without curly braces it is simpler to mess up if you revisit the code, maybe
especially adding ambiguous else conditions.

I'm sure you and the GP would never forget to add curly braces when inserting
an else, but the junior developer who comes afterwards might, and it's just
not a huge deal to have the braces because it's two extra chars.

Quite frankly the Linux kernel coding style is wrong on this one in general, I
guess we can assume they are experienced enough to put braces in when adding
an else clause and so it's not going to cause them errors. But with junior
devs it certainly could.

~~~
gurkendoktor
If you are worried about else conditions, wouldn't this be the way around it?

{if (condition) singleFunctionCall();}

~~~
gurkendoktor
Why is this being downvoted? How do curly braces around the function call help
with ambiguous else branches?

------
quesera
Nice idea.

I took the survey. A few comments:

The early questions show only one sample option. If I remember my survey
design fundamentals, there will likely be a bias in the results for the answer
that matches the sample. This is especially confounding because, as I
interpret it, the sample shown is also the probably-most-common preference.

Later questions have display samples of A, B, C, ... form. Some of the samples
aren't labelled. Minor oversight that the audience should be able to handle,
but it's a source of error.

I'd really like to be able to see the compiled results. Downloading the
rulesets is great, but a browser-digestible form with response weightings
would be much more generally useful.

Also, I can't see the MAS from my iPad, so I can't see the product page. Some
details on the website would be awesome. I think I get it, it's an Xcode
plugin to style-lint my code. How much does it cost? Can it autofix, a la
gofmt?

Even Apple's sample code is full of stylistic inconsistencies, some of which
are distant echoes of K&R vs ANSI C. I like style guides, especially those
that I can customize to my liking.

~~~
lstamour
It's currently listed on the App Store for $4.99 US/CAD. Other countries may
vary. The listing says " __This app is temporarily 50% off! We are very
interested in getting it into the hands of more developers to get more
insights and feedback. Please consider sending us an email about your
experience using our app! Check us out at objclean.com for more information,
and to setup your own custom build configuration file. __"

------
aidenn0
Am I the only one who thought this was going to be adding OO stuff to
Clean[1]?

[1]
[http://en.wikipedia.org/wiki/Clean_(programming_language)](http://en.wikipedia.org/wiki/Clean_\(programming_language\))

------
gte910h
Until they autoformat according to rules, the tool is really painful to use (I
own a license, and tried it)

They've said they're adding it, but it's going in my later list until they get
around to it.

------
schukin
Anyone try AppCode for code formatting? I've noticed many Obj-C developers shy
away from using anything other than Xcode, but AppCode's code formatting is
about as good as it gets.

[http://i.imgur.com/U1i7vlU.png](http://i.imgur.com/U1i7vlU.png)

Disclaimer: I'm in no way affiliated with the developers, I just find it to be
an underrated/overlooked Obj-C IDE.

~~~
rpwilcox
I like Appcode's formatting tools, and could configure it how I like. (I'm
only picky about one or two things stylistically, and one or two things that
affect code generation: what Appcode does when it generates an @property for
me, for example).

I haven't tried sharing these styles across the team who uses AppCode. I'd
really like to be able to share styles across IDEs: if some of the team uses
XCode they could use the style I've defined. But I don't see a way to share
these cross-tool either.

Even Uncrustify integration (export?) for Appcode would be nice, but it's
missing. Heck, I'd even like Uncrustify in AppCode, but haven't found a plugin
for it.

------
fyolnish
[http://universalindent.sourceforge.net](http://universalindent.sourceforge.net)
<\- similar but free

------
danpalmer
Code cleaning is a good idea in general, but when applied everywhere without
consideration it can lead to some odd code in some places. The screenshots
show this throwing errors when it encounters 'malformed' code.

I would much rather it showed warnings, so that I can choose to ignore them if
I think an exception to the rule is better in a specific case. Perhaps it
would be nice if the tool even respected some sort of pragma mark, or other
preprocessor statement so that it can be disabled or partially restricted for
specific parts of the code.

~~~
k-mcgrady
I took their survey and they ask whether you would prefer errors or warnings
for unclean code.

------
mentos
Took the survey, I too would be interested in seeing how other people fall in
line and/or a breakdown of what Github/Apple looks like.

Ideally though one should be able to switch between different styles. I take
it that ObcClean only points the errors out and won't go as far as to correct
them/put them all in one style for you? If not that would be cool.

------
HaloZero
This might be an implementation question you don't want to address but I was
trying to build this using uncrustify but the immense option list proved to be
just complex where it would do certain things that I desired but cause small
inconsistent bugs in other parts of the codebase. Did you end up building your
own or did you just figure out the mess that is Uncrusitify?

------
rismay
I answered around 30 of the questions along with the majority. I only disagree
with around 2 conventions. When the concensus was split 45 / 55, I tended to
be on the 45% side.

I use 2 Xcode Plugins right now: XcodeColors and XAlign.

This could be my third. However, it goes against some XAlign features.

Free app code / $.99 cent sale?

------
tyilo
My ternary style wasn't available in the survey. I prefer to use `a? b: c`
over the two other choices.

------
andrewljohnson
Is there any alternative that will auto format the code, instead of just
throwing an error?

~~~
Simucal
I set this up for my team using Uncrustify and a Git pre-commit hook. It will
reject any commit which has files that don't adhere to our Uncrustify config
file. If it rejects the commit it gives you a command to execute that will
automatically fix your style issues.

~~~
optimusclimb
A thought about this: Years ago I would have agreed, but now I'd strongly
disagree, because of the noise it can add to diffs. When you're triaging a
bug, or trying to figure out what effect someone's change had, you frequently
go back through old commits, and look at the log message to see what the
change was supposed to do. Perhaps a bug or side effect was introduced.

If the diff is full of additional formatting/stylistic changes, it can make it
a lot harder to cut through the noise and get down to the heart of the change.

I'm not saying you should never clean up old code/files, however when I see
that needs to be done, I try to do it in a separate commit that I make after
the "real" change. The log message for that change is something like
"Formatting", or "Cleanup, no functional changes".

~~~
Simucal
Early on in the project we ran Uncrustify across our entire-codebase before
introducing the pre-commit hook. The major downside to this was that git-blame
now pointed to this large commit for almost every line of our project. It
became a pain to trace back changes before the mass style change. Luckily we
did this fairly early in the project so that it hasn't really been a big
problem.

However, because the entire code-base was cleaned up at once we now have no
additional noise from Uncrustify being run on our commits. The only changes to
style it will ever suggest are with your current changes you are attempting to
commit since everything in the repo right now is "clean".

------
UK-AL
Can this be integrated into continuous integration software like jenkins?

------
fosk
Anyone knows if something similar exists for Java/Eclipse?

~~~
rat87
I think there is eclipse checkstyle(eclipse-cs)

plus a findbugs plugin for static analysis(rather then style issues).

------
patrickxb
go fmt

------
goldenkey
Figures that Apple coders would cook something like this up. Seriously,
stylistic habits..are habits. If you need a checker for them, they are no
longer stylistic, they are significant, and you need to remember the patterns.
This is cool but fruitless.

~~~
flyingyeti
You're entitled to your opinion, but code style checking is not something new
and was most likely not cooked up by Apple coders. Checkstyle [1] is a Java
code style tool and has been around since at least 2001.

[1] [http://checkstyle.sourceforge.net/](http://checkstyle.sourceforge.net/)

~~~
goldenkey
I stand corrected. Thank you.

