Investigate clang-format
ericwa opened this issue · comments
I found recently that can set indentation settings for the whole project, which overrides what is set in Preferences. Like this:
http://stackoverflow.com/a/23346801
but you select the root of the project in the xcode left pane.
Nice to know.
Would be nice if the indenter in Xcode wasn't so bad. I keep it turned off usually.
It tends to indent things aggressively no matter what you specify in the Preferences, and gives very little controls over the indenting rules. Also if you pick a tab-based indentation, it doesn't support indenting method keywords as we do with tabs + spaces, to ensure everything is correctly aligned no matter what the tab size is.
Xcode is a pain on this front, especially when you consider other IDE indenters are way better, they are much smarter and less intrusive, plus you can usually specify rules that mix tabs + spaces.
I committed a change to use tab indentation in: ff2fc7b
Without that, Xcode defaults to indenting with spaces and displaying 8-space tabs I think, and you get a huge mess. I'm too lazy indent manually, haha. :P
What we should probably do is set up clang-format to strictly enforce automatic formatting.
Also, mixing tabs and spaces as the Etoile style does is the worst of both worlds in my experience. Since indentation of multi-line method calls is important in ObjC, I would recommend changing the style guide to all spaces with 4 space tabs.
I tried clang-format and it doesn't support - (foo) bar style with the space between ) and bar.
Someone wrote a patch: https://github.com/ebaker355/clang-format but if we're going to use clang-format I want to rely on normal releases.
Also, I couldn't get it to line up the :'s in multi-line method names properly; there is no proper configuration setting for that (see http://stackoverflow.com/questions/22199854/what-clang-format-options-control-format-of-method-calling-parameters ).
So based on the above, clang-format is not usable for us at the moment.
How do you feel about switching to all spaces for indentation?
IMO the benefits of our current style are almost zero (allowing different people to use their own tab width is useless), and the costs are large (can't auto-indent in Xcode, the codebase style is rotting - which is partly my fault.).
At least if we switch to all spaces, we can fix places that are wrong and they will stay fixed
permanently.
Any other options?
I'd be ok to switching to all spaces, if it can help a bit with the formatting.
Whether there is a space between the method name and the return type doesn't matter so much imo. Étoilé coding guidelines states we should have no space like - (NSString *)description.
The only things that really matter to support imo are:
- spaces between method keywords and arguments for both declarations and call sites
- opening and closing braces on their own line
- documentation formatting support based on some character count limit
- spaces around operators
- vertical alignment of method keywords + arguments on ':' for long method names
For many other things, I'd be ok to adjust them e.g. switching from id <SomeProtocol> to id<Protocol>
May be should take a look at Uncrustify, it seems to have around 40 options for ObjC and many more shared with other languages:
http://uncrustify.sourceforge.net/
clang-format seems to be pretty limited with only 4 options for ObjC, so I doubt we can get a decent result without hacking the code base a bit.
For example, it seems there is no option to control spaces between method keywords and arguments.
For Uncrustify, I found the following tools:
For clang-format, I also found this:
It's a pity JetBrains doesn't open source its code formatter, since it's really excellent.
I think all spaces will help. IMHO if we stick to the current mixed tab/space convention, we need to drop support for editing in Xcode and I would need to switch to the JetBrains IDE (I am assuming it supports the Etoile mixed tabs/spaces convention?). That sounds extreme, but the codebase is getting unreadable due to my use of Xcode. e.g. stuff like this showing up..
Another point in favour of all spaces is it permits comments like this which span multiple indentation levels, which are impossible to align for both 4 and 8-space tabs:
If we go with all spaces, how many spaces do you prefer?
AppCode supports mixed tab/space styles, but it's a commercial IDE, so requiring it sounds like a bad idea.
Unless Uncrustify can support mixed tab/space styles well, which I doubt, it's clear that moving to spaces would help a lot. I'm going to take a quick look at Uncrustify.
If we go to all spaces, 4 spaces per tab sounds good, it's the usual tab size. 8 spaces per tab would result in many lines being too long, given the unusual length of ObjC methods names, compared to any other languages.
I took a look at clang-format, there is one major issue with it, there is no way to insert a space between method keywords and arguments. It's kinda weird since that's standard Smalltalk style.
I think AppCode does a pretty good job at code formatting et is easy to configure. If we release a new CoreObject version, we'll be in a better position to ask for a free open source license. The other solutions would be to patch clang-format (libformat precisely) or simply change our coding style. I feel this decreases the readability quite a lot, but it might be better in the long run. Using clang-format would also means reformatting our codebase much more heavily, since it's far less customizable than AppCode code formatter.
Both clang-format and AppCode should be well supported in the future, given they are backed by big companies that have been around for a long time. The only thing that makes me cautious about using clang-format is that Apple doesn't seem to care about the Objective-C support. Unlike with C++ code formatting, they only seem to be interested in supporting their own coding style.
Should we close this issue or do you prefer to keep it opened for a little longer?
We can close it I think