ObjClean(objclean.com)
objclean.com
ObjClean
http://objclean.com/index.html
42 comments
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 (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.
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.
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.
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.
If you are worried about else conditions, wouldn't this be the way around it?
{if (condition) singleFunctionCall();}
{if (condition) singleFunctionCall();}
Why is this being downvoted? How do curly braces around the function call help with ambiguous else branches?
I definitely don't agree with everything in that style guide either, but I can respect it. I think what I like the most is that it's non-judgmental (or when it is judgmental it is clearly sarcasm). It has nice blurbs like "Please at least consider the points made here." - which is the right attitude for a style guide.
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.
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.
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."
You can see the compiled results compared to yours. In the second paragraph:
Click here to view/edit your responses and compare them against the stackoverflow
matrix, as well as the total site average.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)
[1] http://en.wikipedia.org/wiki/Clean_(programming_language)
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.
They've said they're adding it, but it's going in my later list until they get around to it.
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
Disclaimer: I'm in no way affiliated with the developers, I just find it to be an underrated/overlooked Obj-C IDE.
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.
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.
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.
I quite like AppCode, not for code formatting perse. More because it has decent refactoring support, better code analysis+quick fixes, and very keyboard friendly. I still miss the storyboard support though. I do come from a Java background, using Eclipse and IntelliJ. XCode was a bit of a disappointment coming from there.
I remember trying out AppCode and trying to get the syntax configuration to be exactly how I like, but it wasn't possible. (It wasn't something major, but it was still annoying.)
I do agree that AppCode (and IntelliJ) is a nice IDE, but I still stick with Xcode for iOS.
/thread Not sure why any competent iOS developer would be using Xcode (besides poor support for Storyboards which Jetbrains will hopefully sort out). Same thing with any Android developer using Eclipse when IntelliJ is infinitely better.
http://universalindent.sourceforge.net <- similar but free
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.
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.
I took their survey and they ask whether you would prefer errors or warnings for unclean code.
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.
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.
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?
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?
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?
My ternary style wasn't available in the survey. I prefer to use `a? b: c` over the two other choices.
Is there any alternative that will auto format the code, instead of just throwing an error?
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.
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".
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".
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".
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".
Not sure how to integrate it with xcode, but clang-format does pretty decent in emacs.
http://clang.llvm.org/docs/ClangFormatStyleOptions.html
http://clang.llvm.org/docs/ClangFormatStyleOptions.html
If you are willing to switch IDEs, then AppCode can do this. (+ clean up your unused imports). There is currently a bug in formatting Kiwi specs, but is marked as fixed in upcoming build.
Can this be integrated into continuous integration software like jenkins?
go fmt
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.
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/
[1] http://checkstyle.sourceforge.net/
I stand corrected. Thank you.
Checkstyle, FxCop, PEP 8 checkers. These tools have been around for ever, and normally tied into a CI environment.
Well I stand corrected. I code in Objective C myself but I never considered installing an XCode addon or adding a Git hook for simple things like spacing around method name or visibility scope. I guess it would help with large projects but it seems like a problem that is more in line with getting coders to be clean -- not so much an automated thing. Because an automated checker is not going to be able to unshitify messy methods.
Normally bad code is often caused by poor incentives, to get things done quickly, refactoring not appreciated, no unit tests, and managers not caring about good design. Most developers want good code, and it's a fight to get it.
These tools basically makes these things visible and harder to ignore.
These tools basically makes these things visible and harder to ignore.
But the tools would be much better when they get to reformatting and not just giving the programmer more work that is rather painstaking to do. (They are working on this feature, but are afraid of it)
I feel pretty similarly about this...and am an apple coder :D
If the tool reformatted however, I'd have a totally different feeling. That would be great, that it auto goes to some pre-determined, "ok" style for the team without wasting programmer effort doing it.
If the tool reformatted however, I'd have a totally different feeling. That would be great, that it auto goes to some pre-determined, "ok" style for the team without wasting programmer effort doing it.
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:
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...