You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Gregg Wonderly <ge...@cox.net> on 2007/02/01 04:43:07 UTC
Re: thoughts on River project organization...
Jim Hurley wrote:
> If ya'll think this (organization) is a good idea -- I'd
> like to agree on the initial list, where to put it, and
> how best to attack it. Let me know what you think.
One issue that I'd like to bring up, but which may create a lot of disagreement
is the whitespace usage in the JTSK sources. I'd like, at some point, for all
lines of code to have leading tabs only. Everyone seems to like different
whitespace/columns for indentation and tabs only seems to provide the most
flexability. It means that diffs have to be generated with -b, or in some way
which removes whitespace from consideration for any updates people submit
between the old code and their current code.
Am I just retentive about this issue, or does anyone else have some problems
poping the source up in an editor/ide with something besides 8 char tabs?
Gregg Wonderly
Re: thoughts on River project organization...
Posted by Sean Landis <se...@gmail.com>.
I can't resist jumping into the WS wars :-)
First I should say that I use the style the company that signs my
checks tells me to. I am informed that the rulebook is "The Elements
of Java Style." Those sage purveyors of infinite wisdom chose their
very first code-specific topic to be indentation (there were 4
previous topics related to general issues). They recommend 2 SPACES
and so that's how my IDE is configured.
Personally, I prefer spaces to tabs as they lead to fewer surprises.
If I owned this company, I'd say 4 spaces, but I don't. Instead I
follow the rulebook. (Well, almost. I can't abide using a newline
after a "}" to start a catch or else block. A programmer has to draw
the line somewhere! :-)
Sean
Re: thoughts on River project organization...
Posted by Gregg Wonderly <ge...@cox.net>.
Dan Creswell wrote:
> I certainly suffer from the problem but in the most part, especially if
> I'm just reviewing, I'll use a code beautifier.
Since I use perforce for my SCM, all of these sources are read only, in my tree.
The IDE won't let me do anything to the file, without removing the readonly
attribute (by checking it out for edit or otherwise). This creates issues
because I then have to more thoroughly review what I am submitting to make sure
that I didn't beautify something and then edit it inadvertently.
This is mostly about the level of pain that I deal with, and thus, I'm just
whinning a bit, but also trying to suggest that something "better" probably
could be achieved.
Gregg Wonderly
Re: thoughts on River project organization...
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Gregg Wonderly wrote:
> Jim Hurley wrote:
>> If ya'll think this (organization) is a good idea -- I'd
>> like to agree on the initial list, where to put it, and
>> how best to attack it. Let me know what you think.
>
> One issue that I'd like to bring up, but which may create a lot of
> disagreement is the whitespace usage in the JTSK sources. I'd like, at
> some point, for all lines of code to have leading tabs only. Everyone
> seems to like different whitespace/columns for indentation and tabs only
> seems to provide the most flexability. It means that diffs have to be
> generated with -b, or in some way which removes whitespace from
> consideration for any updates people submit between the old code and
> their current code.
>
> Am I just retentive about this issue, or does anyone else have some
> problems poping the source up in an editor/ide with something besides 8
> char tabs?
>
> Gregg Wonderly
>
Hmmmm,
I certainly suffer from the problem but in the most part, especially if
I'm just reviewing, I'll use a code beautifier.
However, the Linux kernel certainly has a standard for this stuff and
that might be indicative of a need to satisfy a need ;)
Dan.
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard, so
> long as it is 4 *spaces* for each level of indentation.
I found the tab is 8 spaces and indentation level is 4 spaces indeed
hard to work with, especially when peeking into the source code when
you have a different number of spaces for your tab.
Although it requires tremendous thinking at some times we should keep
the 80 characters limit, which means people have to work with a fixed
'tab' size anyway.
> Actually, I usually have no problem adapting to whatever the style is of
> the project I'm working on.
Agreed, although the thing I would hate to see is a large numbers of
diffs just as result tab preferences. I have no problem replacing the
tabs in the JTSK code by 8 real spaces and continue with the 4 spaces
indentation, it will keep the formatting the same and will result in
less confusion for there are no tabs anymore. I will have to learn
working with the home key for navigation instead of using the cursor
keys but I think I can adapt to that.
--
Mark
Re: thoughts on River project organization...
Posted by Gregg Wonderly <gr...@wonderly.org>.
Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard, so
> long as it is 4 *spaces* for each level of indentation.
>
> Actually, I usually have no problem adapting to whatever the style is
> of the project I'm working on, but at home, at Artima, we use four
> spaces to indent Java.
War it is :-) I've always used tabs because that was the recommended style that
I learned at college from someone who as involved in a multi-content open source
project with 10 or so contributors. Some liked 4 char spacing, some 3 or even
2. So if everyone used tabs, then they could configure their editor to expand
to what made sense.
I could live with all spaces, but the JTSK source is mixed with lines of all
spaces, all tabs and mixed spaces and tabs. So it's difficult to look at unless
you reconfigure you editor to use 8 char expansion of tabs. It's been a long
time since I've encountered sources with this kind of indentation, so it really
surprised me, and to some degree it's not a big deal, but I am compelled to
realign the indentation so that I can read it with 4 char tabstops, rather than
change all of the settings on the IDE as I switch between JTSK source and my
sources while debugging or developing.
I don't really want to turn this into a big ordeal, I just think that if there
is some agreement, doing this sometime soon would create a much easier to work
with source base, especially for code trollers like me.
Gregg Wonderly
Re: thoughts on River tabs organization...
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
+1
On Feb 1, 2007, at 1:52 AM, Craig L Russell wrote:
> I've been through these wars a number of times and it seems that
> tabs just get in the way of productivity. If you want everything to
> look good and indent 4 spaces, then the usual tab 8 doesn't work,
> even though that's the standard tab. And then you end up with a
> mixture of tabs and spaces in each file, so everyone changes to 4
> space tabs but then people with no tab settings in their editor see
> that there is no spacing at all and put in 4 tabs thinking that
> this will fix things and then no one is happy.
>
> I think 4 space indentation and no tabs seems to be a universal
> solvent. At least very few people object strongly to it.
>
> Craig
>
> On Jan 31, 2007, at 8:13 PM, Bill Venners wrote:
>
>> Hi Gregg,
>>
>> You realize of course this means war. I'm all for a style
>> standard, so long as it is 4 *spaces* for each level of indentation.
>>
>> Actually, I usually have no problem adapting to whatever the style
>> is of the project I'm working on, but at home, at Artima, we use
>> four spaces to indent Java.
>>
>> Bill
>>
>> On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
>>
>>> Jim Hurley wrote:
>>>> If ya'll think this (organization) is a good idea -- I'd
>>>> like to agree on the initial list, where to put it, and
>>>> how best to attack it. Let me know what you think.
>>>
>>> One issue that I'd like to bring up, but which may create a lot
>>> of disagreement is the whitespace usage in the JTSK sources. I'd
>>> like, at some point, for all lines of code to have leading tabs
>>> only. Everyone seems to like different whitespace/columns for
>>> indentation and tabs only seems to provide the most flexability.
>>> It means that diffs have to be generated with -b, or in some way
>>> which removes whitespace from consideration for any updates
>>> people submit between the old code and their current code.
>>>
>>> Am I just retentive about this issue, or does anyone else have
>>> some problems poping the source up in an editor/ide with
>>> something besides 8 char tabs?
>>>
>>> Gregg Wonderly
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: thoughts on River tabs organization...
Posted by Craig L Russell <Cr...@Sun.COM>.
I've been through these wars a number of times and it seems that tabs
just get in the way of productivity. If you want everything to look
good and indent 4 spaces, then the usual tab 8 doesn't work, even
though that's the standard tab. And then you end up with a mixture of
tabs and spaces in each file, so everyone changes to 4 space tabs but
then people with no tab settings in their editor see that there is no
spacing at all and put in 4 tabs thinking that this will fix things
and then no one is happy.
I think 4 space indentation and no tabs seems to be a universal
solvent. At least very few people object strongly to it.
Craig
On Jan 31, 2007, at 8:13 PM, Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard,
> so long as it is 4 *spaces* for each level of indentation.
>
> Actually, I usually have no problem adapting to whatever the style
> is of the project I'm working on, but at home, at Artima, we use
> four spaces to indent Java.
>
> Bill
>
> On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
>
>> Jim Hurley wrote:
>>> If ya'll think this (organization) is a good idea -- I'd
>>> like to agree on the initial list, where to put it, and
>>> how best to attack it. Let me know what you think.
>>
>> One issue that I'd like to bring up, but which may create a lot of
>> disagreement is the whitespace usage in the JTSK sources. I'd
>> like, at some point, for all lines of code to have leading tabs
>> only. Everyone seems to like different whitespace/columns for
>> indentation and tabs only seems to provide the most flexability.
>> It means that diffs have to be generated with -b, or in some way
>> which removes whitespace from consideration for any updates people
>> submit between the old code and their current code.
>>
>> Am I just retentive about this issue, or does anyone else have
>> some problems poping the source up in an editor/ide with something
>> besides 8 char tabs?
>>
>> Gregg Wonderly
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: thoughts on River project organization...
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Gregg:
I'm with Bill on this one; also with Tor from JavaPosse.
http://blogs.sun.com/tor/entry/code_advice_3_no_tabs
Greg.
On Wed, 2007-01-31 at 23:13, Bill Venners wrote:
> Hi Gregg,
>
> You realize of course this means war. I'm all for a style standard,
> so long as it is 4 *spaces* for each level of indentation.
>
> Actually, I usually have no problem adapting to whatever the style is
> of the project I'm working on, but at home, at Artima, we use four
> spaces to indent Java.
>
> Bill
>
> On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
>
> > Jim Hurley wrote:
> >> If ya'll think this (organization) is a good idea -- I'd
> >> like to agree on the initial list, where to put it, and
> >> how best to attack it. Let me know what you think.
> >
> > One issue that I'd like to bring up, but which may create a lot of
> > disagreement is the whitespace usage in the JTSK sources. I'd
> > like, at some point, for all lines of code to have leading tabs
> > only. Everyone seems to like different whitespace/columns for
> > indentation and tabs only seems to provide the most flexability.
> > It means that diffs have to be generated with -b, or in some way
> > which removes whitespace from consideration for any updates people
> > submit between the old code and their current code.
> >
> > Am I just retentive about this issue, or does anyone else have some
> > problems poping the source up in an editor/ide with something
> > besides 8 char tabs?
> >
> > Gregg Wonderly
> >
>
Re: thoughts on River project organization...
Posted by Bill Venners <bv...@artima.com>.
Hi Gregg,
You realize of course this means war. I'm all for a style standard,
so long as it is 4 *spaces* for each level of indentation.
Actually, I usually have no problem adapting to whatever the style is
of the project I'm working on, but at home, at Artima, we use four
spaces to indent Java.
Bill
On Jan 31, 2007, at 7:43 PM, Gregg Wonderly wrote:
> Jim Hurley wrote:
>> If ya'll think this (organization) is a good idea -- I'd
>> like to agree on the initial list, where to put it, and
>> how best to attack it. Let me know what you think.
>
> One issue that I'd like to bring up, but which may create a lot of
> disagreement is the whitespace usage in the JTSK sources. I'd
> like, at some point, for all lines of code to have leading tabs
> only. Everyone seems to like different whitespace/columns for
> indentation and tabs only seems to provide the most flexability.
> It means that diffs have to be generated with -b, or in some way
> which removes whitespace from consideration for any updates people
> submit between the old code and their current code.
>
> Am I just retentive about this issue, or does anyone else have some
> problems poping the source up in an editor/ide with something
> besides 8 char tabs?
>
> Gregg Wonderly
>
RE: thoughts on River project organization...
Posted by "Rollo, Dan" <DR...@ETS.ORG>.
Just to avoid easy consensus...
I prefer no tabs in source code, as it leads to really variable
indentations depending on one's editor. Having to customize your editor
settings according to the tab size of a given project just to get
If/else brackets to line up is not fun. At least with "no tabs", the
indent formatting is always consistent when opened in any editor.
Dan
-----Original Message-----
From: Jeff Ramsdale [mailto:jeff.ramsdale@gmail.com]
Sent: Monday, February 05, 2007 12:17 AM
To: river-dev@incubator.apache.org
Subject: Re: thoughts on River project organization...
Back when we used typewriters we were told to put two spaces between the
period at the end of one sentence and the first character of the next.
This was in order to add visual separation for readability. With the
advent of desktop computers most people continued to put two spaces even
though this actually removed the software's ability to fully and
accurately manage the distance between that period and the following
character.
Most of us use modern IDEs these days. Regardless of historical
precedent concerning spaces the use of tabs provides greater flexibility
within our tools. It's faster to navigate and allows every user to
display their preferred amount of indentation.
Similarly, 80 column line length is just goofy given screen real-estate
these days. I prefer 120. It's time to update the "standards." That
said, I'll go with the group consensus. :-)
Jeff
On 2/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Tabs?
>
> In source?
>
> geir
--------------------------------------------------
This e-mail and any files transmitted with it may contain privileged or confidential information.
It is solely for use by the individual for whom it is intended, even if addressed incorrectly.
If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute,
or take any action in reliance on the contents of this information; and delete it from
your system. Any other use of this e-mail is prohibited.
Thank you for your compliance.
--------------------------------------------------
Re: thoughts on River project organization...
Posted by Calum Shaw-Mackay <ca...@gmail.com>.
Hi all
'First time caller, long time listener......' :)
You can try to enforce code styles such as indentation through
pre-commit hooks in subversion, but this is generally frowned upon, as
ther's no way of getting the reformeted code back to the commiter and
forcing the file to refresh (aka commit and update in the same
operation).
As an aside this could be used for checking for the appropriate
preamble at the top of the file.
Does anyone know if there is a way of moderating commited files for
approval, and as part of this approval, handle the formatting
automatically?
I think the best thing may be get everyone to be fairly happy with the
style, and if someone varies wildly from it, and frown at them evilly
Cheers
--Calum
On 05/02/07, Gregg Wonderly <ge...@cox.net> wrote:
> Mark Brouwer wrote:
> > Jeff Ramsdale wrote:
> >
> >> Similarly, 80 column line length is just goofy given screen
> >> real-estate these days. I prefer 120. It's time to update the
> >> "standards." That said, I'll go with the group consensus. :-)
> >
> >
> > Go wash your mouth Jeff, anybody that performs three-way merges on a
> > regular basis will tell you 80 column width still rulezzzzz.
>
> When I'm doing three way merges, I reformat the affected lines as needed to make
> sense of what is there. Typically though, I don't have too many three way
> merges because we try hard to keep multiple people from working in the same
> areas of files.
>
> When you have to do it though, there are certainly many characteristics of the
> file which create issues for making the merge go fast and correctly.
>
> Gregg Wonderly
>
Re: thoughts on River project organization...
Posted by Gregg Wonderly <ge...@cox.net>.
Mark Brouwer wrote:
> Jeff Ramsdale wrote:
>
>> Similarly, 80 column line length is just goofy given screen
>> real-estate these days. I prefer 120. It's time to update the
>> "standards." That said, I'll go with the group consensus. :-)
>
>
> Go wash your mouth Jeff, anybody that performs three-way merges on a
> regular basis will tell you 80 column width still rulezzzzz.
When I'm doing three way merges, I reformat the affected lines as needed to make
sense of what is there. Typically though, I don't have too many three way
merges because we try hard to keep multiple people from working in the same
areas of files.
When you have to do it though, there are certainly many characteristics of the
file which create issues for making the merge go fast and correctly.
Gregg Wonderly
Re: thoughts on River project organization...
Posted by Mark Brouwer <ma...@cheiron.org>.
Jeff Ramsdale wrote:
> Similarly, 80 column line length is just goofy given screen
> real-estate these days. I prefer 120. It's time to update the
> "standards." That said, I'll go with the group consensus. :-)
Go wash your mouth Jeff, anybody that performs three-way merges on a
regular basis will tell you 80 column width still rulezzzzz.
--
Mark
Re: thoughts on River project organization...
Posted by Jeff Ramsdale <je...@gmail.com>.
Back when we used typewriters we were told to put two spaces between
the period at the end of one sentence and the first character of the
next. This was in order to add visual separation for readability. With
the advent of desktop computers most people continued to put two
spaces even though this actually removed the software's ability to
fully and accurately manage the distance between that period and the
following character.
Most of us use modern IDEs these days. Regardless of historical
precedent concerning spaces the use of tabs provides greater
flexibility within our tools. It's faster to navigate and allows every
user to display their preferred amount of indentation.
Similarly, 80 column line length is just goofy given screen
real-estate these days. I prefer 120. It's time to update the
"standards." That said, I'll go with the group consensus. :-)
Jeff
On 2/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Tabs?
>
> In source?
>
> geir
Re: thoughts on River project organization...
Posted by Gregg Wonderly <gr...@wonderly.org>.
Geir Magnusson Jr. wrote:
> Tabs?
>
> In source?
Well, for 20 years I've used tabs only, and worked in organizations, large at
that, where tabs only was the rule so that people could change the indentation
levels. One of the primary reasons, was reduction in disk space because it was
the 5ESS source tree, the largest in the world at that time. Today (and in this
project) total disk consumption is not an issue. I'm not aware of any widely
used editor which can't be configured to do this exactly right. Doing all
spaces, might be the other choice.
I guess it really depends on what you do every day. Everyday, I use tabs only.
It makes it very fast to move from indentation level to indentation level
using the cursor keys (as Mark alluded to).
I won't try and convince everyone that tabs are better. I'll stop here and just
suggest that either all spaces or all tabs would be better than a mixture.
Gregg Wonderly
Re: thoughts on River project organization...
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tabs?
In source?
geir
On Jan 31, 2007, at 10:43 PM, Gregg Wonderly wrote:
> Jim Hurley wrote:
>> If ya'll think this (organization) is a good idea -- I'd
>> like to agree on the initial list, where to put it, and
>> how best to attack it. Let me know what you think.
>
> One issue that I'd like to bring up, but which may create a lot of
> disagreement is the whitespace usage in the JTSK sources. I'd
> like, at some point, for all lines of code to have leading tabs
> only. Everyone seems to like different whitespace/columns for
> indentation and tabs only seems to provide the most flexability.
> It means that diffs have to be generated with -b, or in some way
> which removes whitespace from consideration for any updates people
> submit between the old code and their current code.
>
> Am I just retentive about this issue, or does anyone else have some
> problems poping the source up in an editor/ide with something
> besides 8 char tabs?
>
> Gregg Wonderly