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 Mike Stover <ms...@apache.org> on 2003/01/05 03:13:01 UTC
[VOTE] code standards, tabs
Your concern is valid. The diff's thing just doesn't bother me much. But if ya'll are
in agreement, then we can just use Sun's standard.
I suppose I'll start the vote. Use Sun's standard for code format (this is also
Apache standard)? -1 for me.
Use Tabs (not spaces) in code: BIG ol' +1 from me. Please, please please....
-Mike
On 4 Jan 2003 at 21:15, Oliver Rossmueller wrote:
> Mike Stover wrote:
> > Re: code-style - I'm not a big fan of standards that insist on X number of spaces,
> > braces have to be here and here, etc. I don't understand why that needs to be
> > standard when, at the push of a button, my IDE makes the code look exactly the
> > way I want it to look. If you don't have such an IDE, there are lots of independent
> > packages that do it, JRefactory being one of the most interesting (available at
> > sourceforge). The only thing I'd like to see is the use of tabs, so no one has to do
> > anything special to get their spacing right.
> >
> > That, however, just points out the real problem - having coding standards doesn't
> > automatically make things easier for everyone. It makes things a pain for those
> > who "lose" the debate, and easier for those who win. I'd rather see everyone win.
> > Get yourself a simple code formatter, and use it on files you edit, if you like.
>
> There is no problem to get the sources formatted the way you like it,
> everybody has an IDE or tool to do this. But the point is: if everybody
> does formatting the way he/she likes it and commits these reformatted
> sources to the cvs you will get lots of diffs not because of changes in
> the implementation but because of reformatting and therefore it is hard
> to see the changes that really matter. In the long run you save a lot of
> time by having a styleguide. Of course this requires some compromises,
> but that's is the way team work goes. So if there is a styleguide we can
> reuse from another jakarta project we should just do it. Otherwise we
> have to find our own.
>
> Oliver
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: code standards, tabs
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Mike Stover wrote:
>>-1, tabs are being dropped by most projects because they make interpretation
>>of the diffs harder, different editors interpret them differently, etc.
>
>
> I don't see how it affects diffs.
When you get diffs with tabs, CVS will insert '-' and '+' characters. With
tabs, the formatting goes to hell and it can be difficult to understand in
which block changes occur. This is my experience. With spaces this is never
a problem.
> And editors interpreting them differently is the whole
> point.
>
Not sure what you mean. The official Sun style guide distinguishes between
tabs and indents. Tabs always take you to a tabstop at multiples of 8. I
believe this is also the emacs standard. So when you set an indent size of
4, the first indent is implemented with 4 spaces and the second level by 1 tab.
A lot of editors, OTOH, use tabs as the indent marker, so setting an indent
size of 4, causes that editor to use 1 tab for the first indent and 2 tabs
for the second indent.
Now think about how the code from each editor looks in the other editor
Case 1:
if (tabs != indent) {
looksBadlyIndented();
}
Case 2:
if (tabs == indent) {
looksBadToo();
}
By using spaces I can be sure that code rendered in your editor is the same
as code rendered in my editor - we see the same thing - and that is good.
So, editors interpreting tabs differently is a bad thing because people will
tend to reformat the code to look right in their editor. :-)
In the end this is probably a religious issue bu the above is why I prefer
spaces.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: code standards, tabs
Posted by Mike Stover <ms...@apache.org>.
> -1, tabs are being dropped by most projects because they make interpretation
> of the diffs harder, different editors interpret them differently, etc.
I don't see how it affects diffs. And editors interpreting them differently is the whole
point.
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] code standards, tabs
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Mike Stover wrote:
> Your concern is valid. The diff's thing just doesn't bother me much. But if ya'll are
> in agreement, then we can just use Sun's standard.
>
> I suppose I'll start the vote. Use Sun's standard for code format (this is also
> Apache standard)? -1 for me.
+1
>
> Use Tabs (not spaces) in code: BIG ol' +1 from me. Please, please please....
>
-1, tabs are being dropped by most projects because they make interpretation
of the diffs harder, different editors interpret them differently, etc.
Just MHO.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] code standards, tabs
Posted by Jordi Salvat i Alabart <js...@atg.com>.
+1 on Sun (& Apache) standards
+1 on Turbine standards
-1 on using tabs (as implied by the previous: Turbine standards forbid tabs)
Mike Stover wrote:
> Your concern is valid. The diff's thing just doesn't bother me much. But if ya'll are
> in agreement, then we can just use Sun's standard.
>
> I suppose I'll start the vote. Use Sun's standard for code format (this is also
> Apache standard)? -1 for me.
>
> Use Tabs (not spaces) in code: BIG ol' +1 from me. Please, please please....
>
> -Mike
>
> On 4 Jan 2003 at 21:15, Oliver Rossmueller wrote:
>
>
>>Mike Stover wrote:
>>
>>>Re: code-style - I'm not a big fan of standards that insist on X number of spaces,
>>>braces have to be here and here, etc. I don't understand why that needs to be
>>>standard when, at the push of a button, my IDE makes the code look exactly the
>>>way I want it to look. If you don't have such an IDE, there are lots of independent
>>>packages that do it, JRefactory being one of the most interesting (available at
>>>sourceforge). The only thing I'd like to see is the use of tabs, so no one has to do
>>>anything special to get their spacing right.
>>>
>>>That, however, just points out the real problem - having coding standards doesn't
>>>automatically make things easier for everyone. It makes things a pain for those
>>>who "lose" the debate, and easier for those who win. I'd rather see everyone win.
>>>Get yourself a simple code formatter, and use it on files you edit, if you like.
>>
>>There is no problem to get the sources formatted the way you like it,
>>everybody has an IDE or tool to do this. But the point is: if everybody
>>does formatting the way he/she likes it and commits these reformatted
>>sources to the cvs you will get lots of diffs not because of changes in
>>the implementation but because of reformatting and therefore it is hard
>>to see the changes that really matter. In the long run you save a lot of
>>time by having a styleguide. Of course this requires some compromises,
>>but that's is the way team work goes. So if there is a styleguide we can
>>reuse from another jakarta project we should just do it. Otherwise we
>>have to find our own.
>>
>>Oliver
>>
>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] code standards, tabs
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Mike Stover wrote:
> Your concern is valid. The diff's thing just doesn't bother me much. But if ya'll are
> in agreement, then we can just use Sun's standard.
>
> I suppose I'll start the vote. Use Sun's standard for code format (this is also
> Apache standard)? -1 for me.
+0, if Sun's standard or Sun's standard & turbine extensions is not
really important for me as long as we have a standard for JMeter.
>
> Use Tabs (not spaces) in code: BIG ol' +1 from me. Please, please please....
-1 because of problems with different editors and in some cases also
cvs. All projects I know of use spaces for indentation and there are
good reasons for this.
Oliver
>
> -Mike
>
> On 4 Jan 2003 at 21:15, Oliver Rossmueller wrote:
>
>
>>Mike Stover wrote:
>>
>>>Re: code-style - I'm not a big fan of standards that insist on X number of spaces,
>>>braces have to be here and here, etc. I don't understand why that needs to be
>>>standard when, at the push of a button, my IDE makes the code look exactly the
>>>way I want it to look. If you don't have such an IDE, there are lots of independent
>>>packages that do it, JRefactory being one of the most interesting (available at
>>>sourceforge). The only thing I'd like to see is the use of tabs, so no one has to do
>>>anything special to get their spacing right.
>>>
>>>That, however, just points out the real problem - having coding standards doesn't
>>>automatically make things easier for everyone. It makes things a pain for those
>>>who "lose" the debate, and easier for those who win. I'd rather see everyone win.
>>>Get yourself a simple code formatter, and use it on files you edit, if you like.
>>
>>There is no problem to get the sources formatted the way you like it,
>>everybody has an IDE or tool to do this. But the point is: if everybody
>>does formatting the way he/she likes it and commits these reformatted
>>sources to the cvs you will get lots of diffs not because of changes in
>>the implementation but because of reformatting and therefore it is hard
>>to see the changes that really matter. In the long run you save a lot of
>>time by having a styleguide. Of course this requires some compromises,
>>but that's is the way team work goes. So if there is a styleguide we can
>>reuse from another jakarta project we should just do it. Otherwise we
>>have to find our own.
>>
>>Oliver
>>
>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
Re: [VOTE] code standards, tabs
Posted by Scott Eade <se...@backstagetech.com.au>.
On 5/01/2003 1:13 PM, "Mike Stover" <ms...@apache.org> wrote:
> Your concern is valid. The diff's thing just doesn't bother me much. But if
> ya'll are in agreement, then we can just use Sun's standard.
>
> I suppose I'll start the vote. Use Sun's standard for code format (this is
> also Apache standard)? -1 for me.
Not sure I get this - you starting a vote with a -1? This doesn't make any
sense.
My personal preference is for curly brackets (braces) to start on a new line
and that they be used even when only one statement is included (as per the
Turbine coding standards
http://jakarta.apache.org/turbine/common/code-standards.html) as this adds
greatly to readability and makes it easier (and less error prone) to add
statements in the future.
I am in the process of evaluating Eclipse as a replacement for IDEA. The
latest version of IDEA allows you to define multiple coding standards and to
allocate these on a project basis, but the latest Eclipse milestone (2.2 M4)
only allows one coding standard to be defined (after a quick search I have
found a checkstyle plugin for eclipse that would appear to support project
specific configurations).
All in all, I am +0 on the coding standard we select, as long as one is
selected.
>
> Use Tabs (not spaces) in code: BIG ol' +1 from me. Please, please please....
+0, but my preference is for spaces (consistent with every other project I
work on).
>
> -Mike
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
.Mac Chat/AIM: seade at mac dot com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>