You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Jeremy Arnold <je...@bigfoot.com> on 2003/08/16 20:39:27 UTC
Code formatting
Hello,
Back in January, the JMeter committers agreed to use the
Jakarta-Turbine conventions for code formatting
(http://jakarta.apache.org/turbine/common/code-standards.html). Not my
personal favorite, but I'm not picky as long as there is some kind of
convention. If you've been watching my commits over the past couple of
months, you'll have noticed I've been working on making the existing
JMeter code conform to this standard. This probably could have been
done with an automated tool, but I used it as an opportunity to become
more familiar with the code. I'm not quite done yet -- JOrphan is not
yet done. And I've really focused mainly on line length, no use of
tabs, and curly brace placement, so there are probably other conventions
that aren't being followed.
So, now that most of the code actually follows the convention, let's
try to stick to it with new code as well. For those of you who use
Eclipse, I added some information to the Wiki (from the main JMeter Wiki
page choose JMeterDevelopment and find the link under "Tools")
describing some settings which work well. If you work on multiple
projects you might consider using a separate Eclipse workspace for
JMeter so that you can have different settings than you might use on
other projects.
Please feel free to update the Wiki with additional suggestions. I
might add some information about using the Checkstyle Eclipse plugin to
catch any incorrect formatting.
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Code formatting
Posted by Jordi Salvat i Alabart <js...@atg.com>.
Jordi Salvat i Alabart: -0
...because the nice thing about standards is that if you don't like any
of the ones out there you can always create your own... (the sentence is
not mine, but I can't remember the author, sorry Mr/Ms. author).
--
Salut,
Jordi.
Jeremy Arnold wrote:
> Hello,
> It looks like people were generally in favor of bumping up the 80
> column width limit, but we didn't really make a decision. It can be
> rather difficult to come to an agreement when we are dealing with a
> sliding scale (80 columns? 100? 120? Personally I prefer 117.5.) So
> let's take it one step at a time. We can start with the question:
>
> Should we increase the 80 column width limit for source code to 100
> columns?
>
> If the result is affirmitive, we can then consider further increasing it
> to 120.
>
> My vote for moving to 100 columns is +1.
>
> Jeremy
> http://xirr.com/~jeremy_a
>
>
> mstover1@apache.org wrote:
>
>> Can we revisit the rule about 80 column width? Who here is doing
>> development in a 640x480 environment? I find the waste of vertical
>> space by something like this annoying:
>>
>> setMethods.add(
>> objectClass.getMethod(
>> "set" + propertyNames[i],
>> new Class[] { propertyClasses[i] }));
>>
>> 80 seems draconian, even for 5 year old monitors. I use 160
>> generally, and I have no trouble seeing an entire line (I use
>> 1600x1200 display size). Something between these two probably
>> constitutes a happy medium for all of us that conserves both vertical
>> and horizontal space.
>>
>> What do people say? Who out there needs an 80 column max? Can people
>> go to 120 or higher?
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
--
Salut,
Jordi.
Re: Code formatting
Posted by Jordi Salvat i Alabart <js...@atg.com>.
Absolutely agree.
Just before "code freeze" prior to each release, maybe?
--
Salut,
Jordi.
mstover1@apache.org wrote:
> Not that I want to extend a discussion on code formatting standards
> longer than I have to, but...
>
> It might be best to disallow code formatting via programmatic
> means (ie, hitting ctrl-shift-F in Eclipse or using pretty printers).
> The reason is that no matter what standards you decide, applying
> such tools will create conflicts. I have already seen this with the
> latest round of formatting.
>
> I like formatting code. I like hitting ctrl-shift-f and seeing everything
> line up, but if multiple people are really going to work on JMeter, it's
> not acceptable that everyone will be doing this to files all over. And
> I think it's unrealistic that people will manually keep their code
> perfect - who counts the columns while they're typing? We do our
> best, but code is going to go out of focus eventually.
>
> So, I suggest we disallow the ad hoc use of code formatting tools,
> and instead, have a regularly scheduled house cleaning that can be
> done when nobody has uncommitted changes outstanding, and
> thus avoid conflicts as best we can. The code is put into nice
> format periodically, and no one ever needs to be browbeaten for
> not complying exactly - we'll just fix it at the end of the month, or
> whatever.
>
> -Mike
>
> On 25 Aug 2003 at 0:02, Jeremy Arnold wrote:
>
>
>>Hello,
>> It looks like people were generally in favor of bumping up the 80
>>column width limit, but we didn't really make a decision. It can be
>>rather difficult to come to an agreement when we are dealing with
>
> a
>
>>sliding scale (80 columns? 100? 120? Personally I prefer
>
> 117.5.) So
>
>>let's take it one step at a time. We can start with the question:
>>
>> Should we increase the 80 column width limit for source code
>
> to 100
>
>>columns?
>>
>>If the result is affirmitive, we can then consider further increasing
>
> it
>
>>to 120.
>>
>> My vote for moving to 100 columns is +1.
>>
>>Jeremy
>>http://xirr.com/~jeremy_a
>>
>>
>>mstover1@apache.org wrote:
>>
>>
>>>Can we revisit the rule about 80 column width? Who here is
>
> doing development in a 640x480 environment? I find the waste of
> vertical space by something like this annoying:
>
>>>setMethods.add(
>>> objectClass.getMethod(
>>> "set" + propertyNames[i],
>>> new Class[] { propertyClasses[i] }));
>>>
>>>80 seems draconian, even for 5 year old monitors. I use 160
>
> generally, and I have no trouble
>
>>>seeing an entire line (I use 1600x1200 display size). Something
>
> between these two probably
>
>>>constitutes a happy medium for all of us that conserves both
>
> vertical and horizontal space.
>
>>>What do people say? Who out there needs an 80 column max?
>
> Can people go to 120 or
>
>>>higher?
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jmeter-dev-
>
> unsubscribe@jakarta.apache.org
>
>>For additional commands, e-mail: jmeter-dev-
>
> help@jakarta.apache.org
>
>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
--
Salut,
Jordi.
Re: Code formatting
Posted by ms...@apache.org.
Not that I want to extend a discussion on code formatting standards
longer than I have to, but...
It might be best to disallow code formatting via programmatic
means (ie, hitting ctrl-shift-F in Eclipse or using pretty printers).
The reason is that no matter what standards you decide, applying
such tools will create conflicts. I have already seen this with the
latest round of formatting.
I like formatting code. I like hitting ctrl-shift-f and seeing everything
line up, but if multiple people are really going to work on JMeter, it's
not acceptable that everyone will be doing this to files all over. And
I think it's unrealistic that people will manually keep their code
perfect - who counts the columns while they're typing? We do our
best, but code is going to go out of focus eventually.
So, I suggest we disallow the ad hoc use of code formatting tools,
and instead, have a regularly scheduled house cleaning that can be
done when nobody has uncommitted changes outstanding, and
thus avoid conflicts as best we can. The code is put into nice
format periodically, and no one ever needs to be browbeaten for
not complying exactly - we'll just fix it at the end of the month, or
whatever.
-Mike
On 25 Aug 2003 at 0:02, Jeremy Arnold wrote:
> Hello,
> It looks like people were generally in favor of bumping up the 80
> column width limit, but we didn't really make a decision. It can be
> rather difficult to come to an agreement when we are dealing with
a
> sliding scale (80 columns? 100? 120? Personally I prefer
117.5.) So
> let's take it one step at a time. We can start with the question:
>
> Should we increase the 80 column width limit for source code
to 100
> columns?
>
> If the result is affirmitive, we can then consider further increasing
it
> to 120.
>
> My vote for moving to 100 columns is +1.
>
> Jeremy
> http://xirr.com/~jeremy_a
>
>
> mstover1@apache.org wrote:
>
> >Can we revisit the rule about 80 column width? Who here is
doing development in a 640x480 environment? I find the waste of
vertical space by something like this annoying:
> >
> >setMethods.add(
> > objectClass.getMethod(
> > "set" + propertyNames[i],
> > new Class[] { propertyClasses[i] }));
> >
> >80 seems draconian, even for 5 year old monitors. I use 160
generally, and I have no trouble
> >seeing an entire line (I use 1600x1200 display size). Something
between these two probably
> >constitutes a happy medium for all of us that conserves both
vertical and horizontal space.
> >
> >What do people say? Who out there needs an 80 column max?
Can people go to 120 or
> >higher?
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-
unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-
help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
Re: Code formatting
Posted by Jeremy Arnold <je...@bigfoot.com>.
Hello,
It looks like people were generally in favor of bumping up the 80
column width limit, but we didn't really make a decision. It can be
rather difficult to come to an agreement when we are dealing with a
sliding scale (80 columns? 100? 120? Personally I prefer 117.5.) So
let's take it one step at a time. We can start with the question:
Should we increase the 80 column width limit for source code to 100
columns?
If the result is affirmitive, we can then consider further increasing it
to 120.
My vote for moving to 100 columns is +1.
Jeremy
http://xirr.com/~jeremy_a
mstover1@apache.org wrote:
>Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of vertical space by something like this annoying:
>
>setMethods.add(
> objectClass.getMethod(
> "set" + propertyNames[i],
> new Class[] { propertyClasses[i] }));
>
>80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
>seeing an entire line (I use 1600x1200 display size). Something between these two probably
>constitutes a happy medium for all of us that conserves both vertical and horizontal space.
>
>What do people say? Who out there needs an 80 column max? Can people go to 120 or
>higher?
>
>
>
>
Re: Code formatting
Posted by Sebastian Bazley <Se...@london.sema.slb.com>.
I also use a high resolution screen, so in theory longer lines are OK.
However, when using Eclipse I like to keep the outline and Navigator panels open on the left hand side, which means that 80-90 is a
reasonable maximum.
For side by side compares, 80 characters is already too much.
Anything much longer than 80 and landscape mode is needed when printing. - this is awkward to use, and tends to use more pages.
So I would vote for remaining with 80-90, not much more.
Sebastian
----- Original Message -----
From: "Jeremy Arnold" <je...@bigfoot.com>
To: "JMeter Developers List" <jm...@jakarta.apache.org>
Sent: Sunday, August 17, 2003 6:11 PM
Subject: Re: Code formatting
Unfortunately, laptops don't have quite the same high-res displays as
desktop systems, and even on my desktop I find that with the usual
Eclipse views my code window ends up being around 80 columns anyway.
That said, I'm happy to bump it up to 120....higher than that seems to
be a bit much to me.
mstover1@apache.org wrote:
>Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of
vertical space by something like this annoying:
>
>setMethods.add(
> objectClass.getMethod(
> "set" + propertyNames[i],
> new Class[] { propertyClasses[i] }));
>
>80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
>seeing an entire line (I use 1600x1200 display size). Something between these two probably
>constitutes a happy medium for all of us that conserves both vertical and horizontal space.
>
>What do people say? Who out there needs an 80 column max? Can people go to 120 or
>higher?
>
>-Mike
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Code formatting
Posted by Sebastian Bazley <Se...@london.sema.slb.com>.
I also use a high resolution screen, so in theory longer lines are OK.
However, when using Eclipse I like to keep the outline and Navigator panels open on the left hand side, which means that 80-90 is a
reasonable maximum.
For side by side compares, 80 characters is already too much.
Anything much longer than 80 and landscape mode is needed when printing. - this is awkward to use, and tends to use more pages.
So I would vote for remaining with 80-90, not much more.
Sebastian
----- Original Message -----
From: "Jeremy Arnold" <je...@bigfoot.com>
To: "JMeter Developers List" <jm...@jakarta.apache.org>
Sent: Sunday, August 17, 2003 6:11 PM
Subject: Re: Code formatting
Unfortunately, laptops don't have quite the same high-res displays as
desktop systems, and even on my desktop I find that with the usual
Eclipse views my code window ends up being around 80 columns anyway.
That said, I'm happy to bump it up to 120....higher than that seems to
be a bit much to me.
mstover1@apache.org wrote:
>Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of
vertical space by something like this annoying:
>
>setMethods.add(
> objectClass.getMethod(
> "set" + propertyNames[i],
> new Class[] { propertyClasses[i] }));
>
>80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
>seeing an entire line (I use 1600x1200 display size). Something between these two probably
>constitutes a happy medium for all of us that conserves both vertical and horizontal space.
>
>What do people say? Who out there needs an 80 column max? Can people go to 120 or
>higher?
>
>-Mike
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Code formatting
Posted by Jeremy Arnold <je...@bigfoot.com>.
Unfortunately, laptops don't have quite the same high-res displays as
desktop systems, and even on my desktop I find that with the usual
Eclipse views my code window ends up being around 80 columns anyway.
That said, I'm happy to bump it up to 120....higher than that seems to
be a bit much to me.
mstover1@apache.org wrote:
>Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of vertical space by something like this annoying:
>
>setMethods.add(
> objectClass.getMethod(
> "set" + propertyNames[i],
> new Class[] { propertyClasses[i] }));
>
>80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
>seeing an entire line (I use 1600x1200 display size). Something between these two probably
>constitutes a happy medium for all of us that conserves both vertical and horizontal space.
>
>What do people say? Who out there needs an 80 column max? Can people go to 120 or
>higher?
>
>-Mike
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Code formatting
Posted by Jeremy Arnold <je...@bigfoot.com>.
Unfortunately, laptops don't have quite the same high-res displays as
desktop systems, and even on my desktop I find that with the usual
Eclipse views my code window ends up being around 80 columns anyway.
That said, I'm happy to bump it up to 120....higher than that seems to
be a bit much to me.
mstover1@apache.org wrote:
>Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of vertical space by something like this annoying:
>
>setMethods.add(
> objectClass.getMethod(
> "set" + propertyNames[i],
> new Class[] { propertyClasses[i] }));
>
>80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
>seeing an entire line (I use 1600x1200 display size). Something between these two probably
>constitutes a happy medium for all of us that conserves both vertical and horizontal space.
>
>What do people say? Who out there needs an 80 column max? Can people go to 120 or
>higher?
>
>-Mike
>
>
Re: Code formatting
Posted by peter lin <jm...@yahoo.com>.
I would be happy with something in between, since I use 19" lcd at home. maybe something that works for 1024 x 768 or 1280 x 1024 would be a good compromise for column width.
peter lin
mstover1@apache.org wrote:
Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of vertical space by something like this annoying:
setMethods.add(
objectClass.getMethod(
"set" + propertyNames[i],
new Class[] { propertyClasses[i] }));
80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
seeing an entire line (I use 1600x1200 display size). Something between these two probably
constitutes a happy medium for all of us that conserves both vertical and horizontal space.
What do people say? Who out there needs an 80 column max? Can people go to 120 or
higher?
-Mike
On 16 Aug 2003 at 20:39, Jeremy Arnold wrote:
> Hello,
> Back in January, the JMeter committers agreed to use the
> Jakarta-Turbine conventions for code formatting
> (http://jakarta.apache.org/turbine/common/code-standards.html). Not my
> personal favorite, but I'm not picky as long as there is some kind of
> convention. If you've been watching my commits over the past couple of
> months, you'll have noticed I've been working on making the existing
> JMeter code conform to this standard. This probably could have been
> done with an automated tool, but I used it as an opportunity to become
> more familiar with the code. I'm not quite done yet -- JOrphan is not
> yet done. And I've really focused mainly on line length, no use of
> tabs, and curly brace placement, so there are probably other conventions
> that aren't being followed.
>
> So, now that most of the code actually follows the convention, let's
> try to stick to it with new code as well. For those of you who use
> Eclipse, I added some information to the Wiki (from the main JMeter Wiki
> page choose JMeterDevelopment and find the link under "Tools")
> describing some settings which work well. If you work on multiple
> projects you might consider using a separate Eclipse workspace for
> JMeter so that you can have different settings than you might use on
> other projects.
>
> Please feel free to update the Wiki with additional suggestions. I
> might add some information about using the Checkstyle Eclipse plugin to
> catch any incorrect formatting.
>
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: Code formatting
Posted by ms...@apache.org.
Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of vertical space by something like this annoying:
setMethods.add(
objectClass.getMethod(
"set" + propertyNames[i],
new Class[] { propertyClasses[i] }));
80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
seeing an entire line (I use 1600x1200 display size). Something between these two probably
constitutes a happy medium for all of us that conserves both vertical and horizontal space.
What do people say? Who out there needs an 80 column max? Can people go to 120 or
higher?
-Mike
On 16 Aug 2003 at 20:39, Jeremy Arnold wrote:
> Hello,
> Back in January, the JMeter committers agreed to use the
> Jakarta-Turbine conventions for code formatting
> (http://jakarta.apache.org/turbine/common/code-standards.html). Not my
> personal favorite, but I'm not picky as long as there is some kind of
> convention. If you've been watching my commits over the past couple of
> months, you'll have noticed I've been working on making the existing
> JMeter code conform to this standard. This probably could have been
> done with an automated tool, but I used it as an opportunity to become
> more familiar with the code. I'm not quite done yet -- JOrphan is not
> yet done. And I've really focused mainly on line length, no use of
> tabs, and curly brace placement, so there are probably other conventions
> that aren't being followed.
>
> So, now that most of the code actually follows the convention, let's
> try to stick to it with new code as well. For those of you who use
> Eclipse, I added some information to the Wiki (from the main JMeter Wiki
> page choose JMeterDevelopment and find the link under "Tools")
> describing some settings which work well. If you work on multiple
> projects you might consider using a separate Eclipse workspace for
> JMeter so that you can have different settings than you might use on
> other projects.
>
> Please feel free to update the Wiki with additional suggestions. I
> might add some information about using the Checkstyle Eclipse plugin to
> catch any incorrect formatting.
>
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Code formatting
Posted by ms...@apache.org.
Can we revisit the rule about 80 column width? Who here is doing development in a 640x480 environment? I find the waste of vertical space by something like this annoying:
setMethods.add(
objectClass.getMethod(
"set" + propertyNames[i],
new Class[] { propertyClasses[i] }));
80 seems draconian, even for 5 year old monitors. I use 160 generally, and I have no trouble
seeing an entire line (I use 1600x1200 display size). Something between these two probably
constitutes a happy medium for all of us that conserves both vertical and horizontal space.
What do people say? Who out there needs an 80 column max? Can people go to 120 or
higher?
-Mike
On 16 Aug 2003 at 20:39, Jeremy Arnold wrote:
> Hello,
> Back in January, the JMeter committers agreed to use the
> Jakarta-Turbine conventions for code formatting
> (http://jakarta.apache.org/turbine/common/code-standards.html). Not my
> personal favorite, but I'm not picky as long as there is some kind of
> convention. If you've been watching my commits over the past couple of
> months, you'll have noticed I've been working on making the existing
> JMeter code conform to this standard. This probably could have been
> done with an automated tool, but I used it as an opportunity to become
> more familiar with the code. I'm not quite done yet -- JOrphan is not
> yet done. And I've really focused mainly on line length, no use of
> tabs, and curly brace placement, so there are probably other conventions
> that aren't being followed.
>
> So, now that most of the code actually follows the convention, let's
> try to stick to it with new code as well. For those of you who use
> Eclipse, I added some information to the Wiki (from the main JMeter Wiki
> page choose JMeterDevelopment and find the link under "Tools")
> describing some settings which work well. If you work on multiple
> projects you might consider using a separate Eclipse workspace for
> JMeter so that you can have different settings than you might use on
> other projects.
>
> Please feel free to update the Wiki with additional suggestions. I
> might add some information about using the Checkstyle Eclipse plugin to
> catch any incorrect formatting.
>
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777