jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Code Style Guidelines
Date Sun, 12 Feb 2017 23:15:32 GMT
On 12 February 2017 at 22:52, Vladimir Sitnikov
<> wrote:
> Philippe>But if possible, I'd prefer that we do not modify too much code
> only for code style as it might make it difficult to look into particular
> regressions.
> I don't think reformatting would complicate things much.
> I think it is fine to settle on some rule(s) (e.g. "space after if", or "no
> wildcard imports" or whatever) and apply the formatting in one go.
> On the positive side, code style violations could be made to fail the
> build. That would prevent bad style creeping into the codebase.
> I have experience with "global reformat" for pgjdbc project (see [1]). That
> was smooth.
> Code formatting made the code more consistent (easier to read, easier to
> update), yet it did not complicate history browsing much.

My experience is that code reformatting makes history browsing very much harder.

> Even thing like "ant -> maven" conversion (with folder reorganization) went
> fine.
> Innocent refactoring like "split big class into a couple of more focused
> ones" brings much more damage in terms of "history traceability". Regular
> tools like "blame/annotate" give no clue that "this particular method was
> moved from that particular file".
> That is why I think it makes sense to just reformat all the files and add
> relevant checkstyle rules when it comes to simple things like "number of
> spaces for indentation", "spaces after if", "brace placement".
> Felix>There would be a lot of warnings. Nobody would look at them after a
> while
> I agree here. The rules should result in build failure on violation, and
> the rules should be easy to configure in IDEs (e.g. autoformat code should
> produce a compliant code)
> [1]:
> Vladimir

View raw message