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...
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.
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."
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] LinaLauneBaer|12 years ago|reply
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...
[+] [-] asveikau|12 years ago|reply
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.
[+] [-] quesera|12 years ago|reply
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|12 years ago|reply
[+] [-] infogulch|12 years ago|reply
[+] [-] aidenn0|12 years ago|reply
[1] http://en.wikipedia.org/wiki/Clean_(programming_language)
[+] [-] gte910h|12 years ago|reply
They've said they're adding it, but it's going in my later list until they get around to it.
[+] [-] schukin|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] joske2|12 years ago|reply
[+] [-] barumrho|12 years ago|reply
[+] [-] trollingineer|12 years ago|reply
[+] [-] fyolnish|12 years ago|reply
[+] [-] danpalmer|12 years ago|reply
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|12 years ago|reply
[+] [-] mentos|12 years ago|reply
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|12 years ago|reply
[+] [-] rismay|12 years ago|reply
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|12 years ago|reply
[+] [-] andrewljohnson|12 years ago|reply
[+] [-] Simucal|12 years ago|reply
[+] [-] mitchty|12 years ago|reply
http://clang.llvm.org/docs/ClangFormatStyleOptions.html
[+] [-] joske2|12 years ago|reply
[+] [-] UK-AL|12 years ago|reply
[+] [-] fosk|12 years ago|reply
[+] [-] rat87|12 years ago|reply
plus a findbugs plugin for static analysis(rather then style issues).
[+] [-] coldtea|12 years ago|reply
[+] [-] patrickxb|12 years ago|reply
[+] [-] goldenkey|12 years ago|reply
[+] [-] flyingyeti|12 years ago|reply
[1] http://checkstyle.sourceforge.net/
[+] [-] UK-AL|12 years ago|reply
[+] [-] gte910h|12 years ago|reply
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.