[cfe-dev] clang-format leading whitespace

Daniel Jasper via cfe-dev cfe-dev at lists.llvm.org
Sun Dec 10 09:02:07 PST 2017


On Sat, Dec 9, 2017 at 2:58 AM, Volodymyr Sapsai <vsapsai at apple.com> wrote:

> As an extra data point I want to tell that even with an automated
> formatter the indented leading whitespace does help. If you re-indent a
> block of code and leading whitespace is preserved, then you get a single
> chunk in the blame of the file. If you eat the leading whitespace then you
> have a million little pieces in the blame and it’s less clear just what
> happened. Something like
>
> 1111bc501498 (John Doe      2015-05-12 09:23:57 +0000  178) if (something)
> {
> 1111bc501498 (John Doe      2015-05-12 09:23:57 +0000  179)   // do
> something
> 2222c3ae83d8 (Adam Smith    2014-12-10 19:00:42 +0000  180)
> 1111bc501498 (John Doe      2015-05-12 09:23:57 +0000  181)   // do some
> more stuff
> 1111bc501498 (John Doe      2015-05-12 09:23:57 +0000  182) }
>
> If leading whitespace was preserved after reindentation you would get a
> single blame chunk. The same applies to diff. Empty lines can make chunks
> too granular.
>

This seems like a very specific and actually quite rare case. And I'd
personally be happy to see some hint that John Doe wasn't actually to blame
for all of those lines (so that I can remember to run "git blame" with
"-w").

As for requirement
>
> be used in a project of significant size
>
>
> I want to point out that preserving leading whitespace on whitespace-only
> lines is Xcode default setting. And as the result many projects can end up
> using this style. For example, a quick check of the top 5 Objective-C
> repositories with the most stars on GitHub
> <https://github.com/search?l=objective-c&o=desc&q=stars:%3E1&s=stars&type=Repositories> shows
> that 3 out of 5 are using predominantly this style
> (rs/SDWebImage, BradLarson/GPUImage, SnapKit/Masonry). It isn’t
> representative in any way, I just want to show that such style isn’t that
> obscure.
>

It totally makes sense for an automated indenter in an editor to add these
leading spaces, but I think the use case is different from a formatter. And
it makes sense for some projects coming from Xcode to not bother to modify
anything afterwards. It doesn't mean that this is the style they *want*.

Thanks,
> Volodymyr
>
> On Nov 13, 2017, at 05:19, Daniel Jasper via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> Generally, see here:
> https://clang.llvm.org/docs/ClangFormatStyleOptions.html#add
> ing-additional-style-options
>
> I vaguely remember this question being brought up before and I think we
> decided against it.
>
> On Mon, Nov 13, 2017 at 2:14 PM, Manuel Klimek via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Sat, Nov 11, 2017 at 7:20 AM Samuel Williams via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> I am interested in contributing to clang-format, to add an option to
>>> preserve and correct leading indentation.
>>>
>>> Right now if you write code such as:
>>>
>>> {
>>> ....int x = 10;
>>> ....
>>> ....return x;
>>> }
>>>
>>> The line in the middle will be truncated and there is no option to
>>> control it.
>>>
>>> Some code prefers to have indented leading whitespace, indented to the
>>> same level as the previous line.
>>>
>>> Would such a contribution be accepted and is anyone willing to help me
>>> through the process where necessary?
>>>
>>
>> The current reasoning is that with an automated formatter the indented
>> leading whitespace doesn't help any more.
>>
>>
>>>
>>> Thanks
>>> Samuel
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171210/fd46662c/attachment.html>


More information about the cfe-dev mailing list