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 Mon, 13 Feb 2017 08:59:30 GMT
sebb>My experience is that code reformatting makes history browsing very
much harder.

Could you give any example here? What particular use case breaks with
single-commit reformatting?

Just to be clear: I don't suggest to reformat the code to some completely
alien format. I suggest to pick a format that suits most part of the
current code.

Let me show an example that "browsing history through reformats" just works.
It is not a theoretical example, but a very real one.

I'll pick v3/QueryExecutorImpl from pgjdbc (that is one of the core class
that implements wire protocol, so its history browsing is important).
Here's what Github shows for the "reformat commit":
[image: 01_github_reformat_diff.png]
Basically, Github shows that "everything was changed".
Indeed the file used to have 4 space for indentation, and it was formatted
with 2 space indentation. Braces were forced after each if/else statement,
etc, etc.
There are 341 differences with "do not ignore whitespace" mode, and there
are 220 differences with "ignore whitespace" mode.

Just for the reference: this file suffered relocation in the source tree on
20.12.2015 as a part of "ant -> maven" migration.

Here's the same file/line opened in IntelliJ as of now:
[image: 02_intellijidea_annotate.png]
You can see how "annotate" attributes lines way back to 2005 even though
almost every line was altered on 29.12.2015 formatting commit.
It just works across reformat and maven migration.

So leading/trailing whitespace changes are harmless.

What happens to "add space after if", "add braces to if" kind of changes?
Of course they are listed in the annotate.
For instance:
[image: 03_brace_added_annotate.png]
Lines 1574 and 1576 are a part of reformat commit that added braces around
Does it make history browsing harder?
I don't think so, as I can just click "annotate previous revision"
[image: 04_annotate_prev_revision.png]
and see how the file looked like before reformatting took place:
[image: 05_prev_revision_annotated.png]
So having a common format is a win as
1) it makes code easier to read, and thus contribute
2) it makes code more robust in face of "goto fail" kind of bugs
3) it still allows decent annotate/history browsing


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