jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Code style
Date Tue, 04 Mar 2014 16:24:55 GMT
Hi,

On Tue, Mar 4, 2014 at 10:47 AM, Davide Giannella
<giannella.davide@gmail.com> wrote:
> I'm saying that with the proper tool in place this would have not happened
> as the build would (potentially) break if the formatting is not good.

The trouble with such tooling is avoiding false positives. Where do
you draw the line on valid formatting?

For example many of the formatting changes in the troublesome patch
seem equally valid before and after the change. Which one should such
a tool prefer, and why?

Basic stuff like using spaces instead of tabs would probably be OK to
enforce in the default build, but already things like the correct
indentation level becomes troublesome to enforce automatically. There
are cases where it makes sense to break or bend the formatting rules
for better readability, and I'd hate to loose that flexibility because
of too strict formatting checks.

> In any case I could have a precise report of file name and line number
> of what is wrong and at the end even the committer should not care about
> the formatting as a tool is taking care of it by highlighting in case of
> problems.

When submitting a patch, it's always a good practice to actually take
a look at the diff and make sure that all the intended changes are
included and nothing else. Just a few seconds of looking at
https://github.com/apache/jackrabbit-oak/pull/9/files shows the
problem.

BR,

Jukka Zitting

Mime
View raw message