On Jan 6, 2014, at 17:10, Karl Tomlinson <mozn...@karlt.net> wrote:
> Gregory Szorc writes:
>
>> I think you just gave an example of why our tooling needs to
>> identify poorly formatted code better. An "if" without a brace
>> followed by multiple indented lines containing compiler
>> expressions is a bug at worst or unreadable/unclear code at
>> best. We could, of course, identify such poor style before any
>> automated style conversion. In any case, looking at a file
>> revision from before the automated brace insertion would clearly
>> reveal the author's [likely] intent. I therefore fail to see your
>> concern here.
>
> Consider
>
> if (condition1)
> if (condition2)
> foo();
> else
> bar();
>
> Automated style conversion would make this
>
> if (condition1) {
> if (condition2) {
> foo();
> } else {
> bar();
> }
> }
>
> No one is likely to look at the file revision before the style
> conversion, but someone might look through the trunk revision.
> The bug is initially visible but well hidden by the conversion.
>
> The bug is hidden almost as well by conversion of only indentation.
>
> if (condition1)
> if (condition2)
> foo();
> else
> bar();
>
> Sure, you could argue that style conversion makes the actual
> behaviour clearer, but you'd have to know the intended behaviour
> to know there was a bug.
>
> If we have a tool to skip the style change on any such unclear
> situations, then perhaps we can proceed more safely.
The clang formatter accepts lines, columns, or byte offsets to reformat. If we
can identify nebulous blocks, we can construct arguments to ignore them. Better
yet, we teach the clang formatter how to recognize nebulous scenarios (if it
doesn't already).
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
