jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: Code Style Guidelines
Date Sun, 12 Feb 2017 08:41:00 GMT
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 <graham@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
>>
>
>


Mime
View raw message