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 21:46:33 GMT
Jeremiah>The project was internal and I cannot show it publicly.

Can you clarify which kind of changes did take place?
Was there a code movement (e.g. methods, variables, fields rearranged)?
Class refactoring (e.g. method moved to another class)?

There's no magic. git-blame can ignore whitespace changes just fine, so
please provide some meaningful details.

I claim that reformat (that is whitespace changes + minor cleanups like
"adding braces to if") add little to no overhead on history browsing.

Of course, code movement (method movement inside a file / across files)
create great overhead on history browsing.
If that was your case, please read
again and note that I have never suggested to move code around.
What I suggest is to agree on whitespace policy, apply it and implement a
relevant CI check.

Jeremiah>Avoid repeating things that cause pain.

Exactly. That is why I suggest to setup a policy that will ensure that
ill-formatted code never reaches trunk.
So we reformat the code once and make sure the code is always in a good

Jeremiah>Have you?  From my perspective, you haven't shown much of anything
Jeremiah>we don't see your images

Can you clarify if you have seen a URL listed in this message:

I did not generate a screenshot for ReportGeneratorConfiguration (that is
part of JMeter), however I see no much point in doing that. Everyone can
just "git blame" that file and see that formatting by Felix did not break

Jeremiah>Regardless, you cannot possibly expect everyone
Jeremiah>to use your exact tooling just to browse project history?

Bot yes and no.

Exactly the same "blame results with whitespace being ignored" can be
produced by regular command line and UI tools.
For instance, here are the tools that come with git/svn:  git blame
<filename>; svn blame <filename>, git gui blame <filename>
There are options to honor/ignore whitespace changes in both git and svn.
What's the problem with history browsing?

However, the one who browses history might need some cross-reference,
navigation and other IDE features that are not available in dump console.
If that is the case, he/she picks an IDE.

There are free & open source IDEs that can do history browsing (e.g. IDEA,
Netbeans), so I see no reason to vote based on "this particular feature
does not work in Eclipse as of 2012-mm-dd" feeling.
Note: I take sebb's words "the feature is missing in Eclipse" for granted.
It might be the feature has already been implemented (e.g. for git or


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