jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: Code Style Guidelines
Date Sun, 12 Feb 2017 22:52:28 GMT
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

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.

Even thing like "ant -> maven" conversion (with folder reorganization) went

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

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)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message