Hello,
The JMeterEclipse have need to be update with a most casual code style
(current resolution of computer's screen are more greater than in 2003,
so the length of line can be more longer for example)
I'm agree with Philippe about avoid to change the current code for
formatting to keep an easy way to compare version of a file. We can just
use the code formating for the new contributions (on whole files or just
on the lines updates in an 'old' file)
Milamber
On 11/02/2017 23:14, Philippe Mouawad wrote:
On Sat, Feb 11, 2017 at 11:27 PM, Graham Russell <gra...@ham1.co.uk> wrote:
Hi all
Do we have any (written) guidance on code style?
I know we have checkstyle, but this has very few rules.
The reason for asking is that I think having a consistent style is very
important for readability (which helps writing new feature or fixing
existing code etc.).
The main things I think contribute to this are (and which are fairly easy
to detect/fix):
* (soft) line lengths (80, 100?)
* spacing between elements on a line e.g. if (..., while (...,
methodCall(arg1, arg2), "con" + "cat"
If this is related to String concat, we should only do that in places where
performance is not a critical point as IMU StringBuilder concat is still
better than '+'
* import order, spacing and not using .*
* line length of methods (soft limit of 50?)
* line length of classes (soft limit of 500?)
I am ok with these proposals and providing a checkstyle and Eclipse
formatter might be very useful.
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.
So maybe do that on new code or when changing a file for something else..
From Phillippe's Java 8 email:
* Use of Optional
>From the document, I understand Optional has a memory/performance impact so
we need to take this into account where we decide to apply it.
But I'm ok with it.
* Default/static methods on Interfaces
+1
* Lambas where possible (max ~5 lines?)
+1 provided reduced code is more readable than existing one. If it's
reduced but we have to scratch our head to understand it I'm not sure it's
a gain :-)
Regarding Streams, we need to be sure of performance impact. And It appears
Sonar has some issues analyzing such code
I have found this: https://wiki.apache.org/jmeter/JMeterEclipse
which suggests some formatting e.g. 80 char line length and new line before
opening brace but most of the code doesn't conform to that - it was also
updated 8 years ago.
Any other ideas/thoughts?
Thanks
Graham
