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 <gr...@wonderly.org> on 2010/12/02 15:40:47 UTC
Formatting of River Source Tree
As I've said here before and elsewhere, I really feel that tabs only is the most
beneficial indentation to use. The reason is that it allows people who use odd
tab intervals to still see things and use their tab key while editing without
having to change their IDE settings while editing.
Sun has an old formatting document that discusses using spaces only, and
netbeans does this by default. The biggest issue for me, of course, is that I
use 4 character tab expansion and tabs only in all of my development.
In an open source world, all tabs is really the only thing that provides the
most flexibility it seems to me.
Gregg Wonderly
Re: Formatting of River Source Tree
Posted by Benson Margulies <bi...@gmail.com>.
Well, that depends on the policy that individual developers are
entitled to pick their own view of the code. Many open source projects
use spaces exactly to ensure that everyone sees exactly the same
thing.
On Thu, Dec 2, 2010 at 9:40 AM, Gregg Wonderly <gr...@wonderly.org> wrote:
> As I've said here before and elsewhere, I really feel that tabs only is the
> most beneficial indentation to use. The reason is that it allows people who
> use odd tab intervals to still see things and use their tab key while
> editing without having to change their IDE settings while editing.
>
> Sun has an old formatting document that discusses using spaces only, and
> netbeans does this by default. The biggest issue for me, of course, is that
> I use 4 character tab expansion and tabs only in all of my development.
>
> In an open source world, all tabs is really the only thing that provides the
> most flexibility it seems to me.
>
> Gregg Wonderly
>
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 02-12-10 15:54, Dennis Reedy wrote:
> +1 for spaces over tabs
>
+1
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Formatting of River Source Tree
Posted by Dennis Reedy <de...@gmail.com>.
On Dec 2, 2010, at 950AM, Patricia Shanahan wrote:
> Gregg Wonderly wrote:
>> As I've said here before and elsewhere, I really feel that tabs only is the most beneficial indentation to use. The reason is that it allows people who use odd tab intervals to still see things and use their tab key while editing without having to change their IDE settings while editing.
>> Sun has an old formatting document that discusses using spaces only, and netbeans does this by default. The biggest issue for me, of course, is that I use 4 character tab expansion and tabs only in all of my development.
>> In an open source world, all tabs is really the only thing that provides the most flexibility it seems to me.
>
> My current approach in making changes to River is to try to be consistent with the code around the change.
>
> I am very strongly opposed to mixing tabs and space, because it loses indentation consistency unless viewed with the same tab size as was used to create it.
>
> I prefer all spaces because it avoids the nasty over-indentation you get if all tabs is viewed in with 8 spaces per tab. For example, tabbed code has real problems when quoted in mail or newsgroup messages. However, I'm generally willing to be flexible about this sort of thing.
+1 for spaces over tabs
Re: Formatting of River Source Tree
Posted by Patricia Shanahan <pa...@acm.org>.
Gregg Wonderly wrote:
> As I've said here before and elsewhere, I really feel that tabs only is
> the most beneficial indentation to use. The reason is that it allows
> people who use odd tab intervals to still see things and use their tab
> key while editing without having to change their IDE settings while
> editing.
>
> Sun has an old formatting document that discusses using spaces only, and
> netbeans does this by default. The biggest issue for me, of course, is
> that I use 4 character tab expansion and tabs only in all of my
> development.
>
> In an open source world, all tabs is really the only thing that provides
> the most flexibility it seems to me.
My current approach in making changes to River is to try to be
consistent with the code around the change.
I am very strongly opposed to mixing tabs and space, because it loses
indentation consistency unless viewed with the same tab size as was used
to create it.
I prefer all spaces because it avoids the nasty over-indentation you get
if all tabs is viewed in with 8 spaces per tab. For example, tabbed code
has real problems when quoted in mail or newsgroup messages. However,
I'm generally willing to be flexible about this sort of thing.
Patricia
Re: Formatting of River Source Tree
Posted by Wade Chandler <hw...@yahoo.com>.
Right. We use both findbugs and checkstyle on a project. I meant to write
CheckStyle instead. Indeed, it could help with this.
Wade
==================
Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
> From: Christopher Dolan <ch...@avid.com>
> To: river-dev@incubator.apache.org
> Sent: Mon, December 6, 2010 11:59:13 AM
> Subject: RE: Formatting of River Source Tree
>
> FindBugs looks at .class files, not source code. The CheckStyle tool or
> the recently-opensourced CodePro tool could help with this.
>
> +0.2 to spaces (I don't care enough for a full +1). The JDK is a prime
> example of tabs done wrong.
>
> Chris
>
> -----Original Message-----
> From: Wade Chandler [mailto:hwadechandler-apache@yahoo.com]
> Sent: Sunday, December 05, 2010 3:31 PM
> To: river-dev@incubator.apache.org
> Subject: Re: Formatting of River Source Tree
>
> ----- Original Message ----
>
> > From: Patricia Shanahan <pa...@acm.org>
> > To: river-dev@incubator.apache.org
> > Sent: Sun, December 5, 2010 1:26:04 PM
> > Subject: Re: Formatting of River Source Tree
> >
> > The good news about spaces is that the code will display with
> reasonable
> > indentation in *all* environments, including e.g. quotes in e-mail,
> > regardless of the choice of e-mail client.
> >
>
> Yes, and if it is really too big a deal, then something like findbugs
> can be
> used to report issues without failing the build and blame can be used to
> keeps
> folks correcting any issues with tabs or space setting differences. In
> the wiki
> some minor processes could be defined. A simple page "Working with the
> sources"
> with hints should suffice. My opinion anyways. I prefer spaces.
>
> Wade
>
> ==================
> Wade Chandler
> Software Engineer and Developer
> NetBeans Dream Team Member and Contributor
>
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
>
>
RE: Formatting of River Source Tree
Posted by Christopher Dolan <ch...@avid.com>.
FindBugs looks at .class files, not source code. The CheckStyle tool or
the recently-opensourced CodePro tool could help with this.
+0.2 to spaces (I don't care enough for a full +1). The JDK is a prime
example of tabs done wrong.
Chris
-----Original Message-----
From: Wade Chandler [mailto:hwadechandler-apache@yahoo.com]
Sent: Sunday, December 05, 2010 3:31 PM
To: river-dev@incubator.apache.org
Subject: Re: Formatting of River Source Tree
----- Original Message ----
> From: Patricia Shanahan <pa...@acm.org>
> To: river-dev@incubator.apache.org
> Sent: Sun, December 5, 2010 1:26:04 PM
> Subject: Re: Formatting of River Source Tree
>
> The good news about spaces is that the code will display with
reasonable
> indentation in *all* environments, including e.g. quotes in e-mail,
> regardless of the choice of e-mail client.
>
Yes, and if it is really too big a deal, then something like findbugs
can be
used to report issues without failing the build and blame can be used to
keeps
folks correcting any issues with tabs or space setting differences. In
the wiki
some minor processes could be defined. A simple page "Working with the
sources"
with hints should suffice. My opinion anyways. I prefer spaces.
Wade
==================
Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
Re: Formatting of River Source Tree
Posted by Wade Chandler <hw...@yahoo.com>.
----- Original Message ----
> From: Patricia Shanahan <pa...@acm.org>
> To: river-dev@incubator.apache.org
> Sent: Sun, December 5, 2010 1:26:04 PM
> Subject: Re: Formatting of River Source Tree
>
> The good news about spaces is that the code will display with reasonable
> indentation in *all* environments, including e.g. quotes in e-mail,
> regardless of the choice of e-mail client.
>
Yes, and if it is really too big a deal, then something like findbugs can be
used to report issues without failing the build and blame can be used to keeps
folks correcting any issues with tabs or space setting differences. In the wiki
some minor processes could be defined. A simple page "Working with the sources"
with hints should suffice. My opinion anyways. I prefer spaces.
Wade
==================
Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/12/2010 12:31 PM, Patricia Shanahan wrote:
> Older sources are best viewed with tab stops at 8 space
> intervals", to make it clearer that we should not be generating more
> mixed tabs-and-spaces code.
Done.
Gr. Sim
Re: Formatting of River Source Tree
Posted by Patricia Shanahan <pa...@acm.org>.
On 12/12/2010 3:03 AM, Sim IJskes - QCG wrote:
> On 12/10/2010 11:34 PM, Gregg Wonderly wrote:
>> Okay, this is good news, and I guess I just did not see this being
>> added. I've turned on per project formatting for the Jini tree as "tabs
>> are 8" and "indentation is 4" and that makes a huge difference in
>> readability. So maybe I can just relax a bit about this issue.
>
> I've added a small note about the tabstops. Everybody in agreement?
>
> Gr. Sim
>
>
> # Coding conventions
>
> ## Indentation
> Tabs are not used. Default indentation is 4 spaces.
>
> ## Other
> Contributors are advised to read
> <http://www.oracle.com/technetwork/java/codeconv-138413.html>
> and try to adhere as much as possible to these conventions.
>
> ## Older sources
> We do not actively search and reformat source files
> that are not formatted according to this convention.
>
> Tab stops are considered to be on 8 spaces interval.
>
>
I would prefer "Older sources are best viewed with tab stops at 8 space
intervals", to make it clearer that we should not be generating more
mixed tabs-and-spaces code.
The tabs vs. spaces argument is a trade-off between the flexibility of
all tabs and the reliably readable display in all environments of all
spaces. Mixing tabs and spaces gets the worst of both worlds. It must be
viewed with one specific tab setting.
Patricia
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 13-12-10 11:51, Peter Firmstone wrote:
> I'll spend some time going through the docs now in preparation for release.
Shall we record this process in a webpage?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Formatting of River Source Tree
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> I'm done. I've added my last contribution to the webpage in staging.
>
> http://river.staging.apache.org/river/coding.html
>
> Gr. Sim
>
Thanks Sim,
I hadn't noticed the build doc's are now built separately, ignore my
earlier comments, just me getting confused. Excellent work, much
appreciated.
I'll spend some time going through the docs now in preparation for release.
Cheers,
Peter.
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
I'm done. I've added my last contribution to the webpage in staging.
http://river.staging.apache.org/river/coding.html
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Formatting of River Source Tree
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Dec 13, 2010 at 4:12 AM, Benson Margulies <bi...@gmail.com> wrote:
> Here's a voice of possibly non-relevant experience.
Some more non-relevant experience;
Once upon a time, 24 years ago to be exact, we had released a
industrial automation system in version 1.0, and shipped something
like 100+ devices. There were a bunch of things we didn't get right,
especially in the serial communication department inside our devices.
So, I started a re-write of that, and suggested that we should change
the both the 'default device address' (from 254:30 to 0:0) as well as
the 'broadcast address' (from 255:31 to 255:255), but the 'legacy
argument' came up; "This would serious affect all the existing users,
have to learn a new address... bla bla bla", so it wasn't changed.
Instead, for the next 24 years, batch after batch of new developers
learning the system, would ask "Why those numbers?" and endless effort
explaining the pre-historic details where they came from.
Point I am trying to drive home;
It is almost always better to take a large one-time hit, when
something is seriously wrong, to create a time zero (t0), the Iridium
layer in time, than maintaining that 'legacy' is more important. Doing
so, you come across as "playing to not loose" instead of "playing to
win".
If you need to go looking for regression prior to that date, yes you
will need better diff tools (those diff tools that ignore whitespace
changes). But, if you think River is going to be here for the
long-haul, the majority of your regression will happen 'later than
now'.
Hence, take the big reformat hit, get a 'nice state' now, prior to
your "t0" release, and put in place Checkstyle to keep an eye on it,
like Benson suggests.
People has pointed out that "set the tab to 8 and indentation to 4 for
the project"; Well, that works for the developers on River, but
doesn't help "me", the user of River. When I have my settings,
differently, and stepping through the River sources inside *my
project*, I get the buggered up "mixed style", incoherent (if so)
formatting of braces, whitespace and so forth. I enjoy readable code,
even if the code is not formatted to my preferred style. I'll choose
CXF, Maven or Spring any day over the JDK, Jini and other 'mixed
style', whether that be in tabs/spaces or other styling.
Speaking as a user; Please don't forget us. Not everyone reading River
code are doing so within the River developer community, working on
fixing River bugs,.
And as Benson; This is a free, one-time advice, not a stance of mine,
use it to the best of your knowledge...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/12/2010 10:42 PM, Benson Margulies wrote:
> If I go to fix something, I never have to worry about meticulously
> maintaining some strange code format that someone, once upon a time,
> checked in. If I need to change the block structure, I can always tell
> Eclipse to reformat, and know that it won't result in radical changes
> or annoyed fellow contributors.
Once donated to the apache codebase it's basically free game for
everyone. If you are going to fix some problem, you can reformat in any
format you like, within reason. no code puzzles please :-).
You can take eclipse, reformat the codeblock you want to fix, and if you
have fixed the bug, we should all cheer from enjoyment. If not we will
still be happy with your efforts.
Who codes, determines. "qui codes determinat".
Gr. Sim
Re: Formatting of River Source Tree
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 12/12/2010 10:42 PM, Benson Margulies wrote:
>> I'm not going to battle on this, but I would invite you to consider
>> the comparison to CXF. It's very large, and we've never had anyone
>> drive off in a huffman code because they hated the standardized
>> format. It's not 'heavenly', it's the fact that you always know what
>> you are looking at because the code base is uniform.
>
> BTW: the comments about heavenly were not directed at the CXF
> approach, but described experiences i had with programmers entering a
> team, and the first they did was 'doing the rest a favor' by
> reformatting the complete codebase.
>
> I was also remembering the endless arguments, of which format was a
> tiny bit better than the other. My approach is, focus, if it is not
> relevant to solving the bug, stay away from it.
>
> If you need to reformat in order to be able to fix the bug, do it.
>
> The only technical barrier whe have is the line oriented nature of
> generating deltas or diffs in the svn.
>
> Gr. Sim
Kent Beck has a nice little book on refactoring to make code easier to
read and maintain.
I think it's important to understand the piece of code your playing
with, before altering functionality, sometimes refactoring is an
important part of the process if code's hard to read.
Code churn doesn't help much when tracking down a heisenbug ;) But I'm
more in favour of improving my debugging skills than restricting other
peoples efforts to maintain code, provided tests are run before committing.
Cheers,
Peter.
Re: Formatting of River Source Tree
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Dec 13, 2010 at 12:19 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> The only technical barrier whe have is the line oriented nature of
> generating deltas or diffs in the svn.
A related fact that I didn't yet see mentioned in this thread: The
original code contribution from Sun didn't come with a
version-controlled history, so we only have "svn blame" records going
back to 2007. Thus, if you do reformat a class, in most cases there's
no need to worry too much about breaking code history.
BTW, Sim, I really like your approach of incrementally capturing
emerging consensus on a web page!
BR,
Jukka Zitting
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/12/2010 10:42 PM, Benson Margulies wrote:
> I'm not going to battle on this, but I would invite you to consider
> the comparison to CXF. It's very large, and we've never had anyone
> drive off in a huffman code because they hated the standardized
> format. It's not 'heavenly', it's the fact that you always know what
> you are looking at because the code base is uniform.
BTW: the comments about heavenly were not directed at the CXF approach,
but described experiences i had with programmers entering a team, and
the first they did was 'doing the rest a favor' by reformatting the
complete codebase.
I was also remembering the endless arguments, of which format was a tiny
bit better than the other. My approach is, focus, if it is not relevant
to solving the bug, stay away from it.
If you need to reformat in order to be able to fix the bug, do it.
The only technical barrier whe have is the line oriented nature of
generating deltas or diffs in the svn.
Gr. Sim
Re: Formatting of River Source Tree
Posted by Benson Margulies <bi...@gmail.com>.
Sim,
I'm not going to battle on this, but I would invite you to consider
the comparison to CXF. It's very large, and we've never had anyone
drive off in a huffman code because they hated the standardized
format. It's not 'heavenly', it's the fact that you always know what
you are looking at because the code base is uniform.
If I go to fix something, I never have to worry about meticulously
maintaining some strange code format that someone, once upon a time,
checked in. If I need to change the block structure, I can always tell
Eclipse to reformat, and know that it won't result in radical changes
or annoyed fellow contributors.
However, far be it from me to tell all of you what to do.
--benson
On Sun, Dec 12, 2010 at 3:31 PM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> Just in general, some programmers have to battle with all kinds of neurosis.
> Sometimes this involves an unmitigateable urge to reformat everything to 1
> single heavenly standard.
>
> You can't do this with a large codebase. First of all there is no heaven in
> coding standards, and second i don't want to deprive river of a contribution
> because some programmer just feels his or hers contribution should be in
> some format.
>
> I'm happy when somebody contributes. In any format.
>
> Gr. Sim
>
>
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
Just in general, some programmers have to battle with all kinds of
neurosis. Sometimes this involves an unmitigateable urge to reformat
everything to 1 single heavenly standard.
You can't do this with a large codebase. First of all there is no heaven
in coding standards, and second i don't want to deprive river of a
contribution because some programmer just feels his or hers contribution
should be in some format.
I'm happy when somebody contributes. In any format.
Gr. Sim
Re: Formatting of River Source Tree
Posted by Benson Margulies <bi...@gmail.com>.
Here's a voice of possibly non-relevant experience.
At CXF, we have a standard format, and we include in the tree all the
fixing needed to configure eclipse for that format. And we configure
checkstyle to fail the build for deviations from the format. This
certainly avoids all controversy about the format. All contributors
are assimilated.
Now, assuming that the River project wants to aim at a similar state
of affairs, how to get there? A little at a time, or with gusto?
If you want to turn on checkstyle and get value out of it, you need to
indeed reformat. You can put //CHECKSTYLE:OFF on everything and remove
it as things get reformatted to achieve an incremental result, but
then you're not getting much value in my opinion.
Keep in mind that I'm a card-carrying Bolshie when it comes to this
sort of thing. What I'd do is agree the checkstyle/format criteria,
then freeze the tree, and use eclipse 'CleanUp' to reformat the
universe, check in, and get on with life. But that's me.
--benson
On Sun, Dec 12, 2010 at 3:03 PM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 12/12/2010 06:37 PM, Greg Trasuk wrote:
>>
>> Suggestion:
>>
>> ## Older sources
>> We do not actively search and reformat source files
>> that are not formatted according to this convention.
>>
>> When a coder edits an older source file some reason (e.g. bug fixes or
>> feature additions), he/she should reformat the file according to these
>> specs. He/she should commit the reformatting separately, so as to
>> separate reformatting changes from actual code changes.
>
> I've reread the thread, and i have to agree with Christopher.
>
> Reformatting a whole class in order to fix a small bug, doesn't feel right.
> I would just reformat the method or just around the bug.
>
> When we limit ourselfs to a small reformat footprint, a inbetween commit
> doesn't add that much. At least IMHO.
>
> I'm begging for wisdom here. Maybe we should write:
>
> "If the reformatting involves a large part of the code, a clearly labeled
> 'reformatting' commit in between is recommended. Keeping your reformatting
> changes limited, reduces the change of merging conflicts by your fellow
> committers."
>
> Did i find the right words?
>
> Gr. Sim
>
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/12/2010 06:37 PM, Greg Trasuk wrote:
> Suggestion:
>
> ## Older sources
> We do not actively search and reformat source files
> that are not formatted according to this convention.
>
> When a coder edits an older source file some reason (e.g. bug fixes or
> feature additions), he/she should reformat the file according to these
> specs. He/she should commit the reformatting separately, so as to
> separate reformatting changes from actual code changes.
I've reread the thread, and i have to agree with Christopher.
Reformatting a whole class in order to fix a small bug, doesn't feel
right. I would just reformat the method or just around the bug.
When we limit ourselfs to a small reformat footprint, a inbetween commit
doesn't add that much. At least IMHO.
I'm begging for wisdom here. Maybe we should write:
"If the reformatting involves a large part of the code, a clearly
labeled 'reformatting' commit in between is recommended. Keeping your
reformatting changes limited, reduces the change of merging conflicts by
your fellow committers."
Did i find the right words?
Gr. Sim
Re: Formatting of River Source Tree
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Sun, 2010-12-12 at 06:03, Sim IJskes - QCG wrote:
> On 12/10/2010 11:34 PM, Gregg Wonderly wrote:
> > Okay, this is good news, and I guess I just did not see this being
> > added. I've turned on per project formatting for the Jini tree as "tabs
> > are 8" and "indentation is 4" and that makes a huge difference in
> > readability. So maybe I can just relax a bit about this issue.
>
> I've added a small note about the tabstops. Everybody in agreement?
>
Suggestion:
## Older sources
We do not actively search and reformat source files
that are not formatted according to this convention.
When a coder edits an older source file some reason (e.g. bug fixes or
feature additions), he/she should reformat the file according to these
specs. He/she should commit the reformatting separately, so as to
separate reformatting changes from actual code changes.
Cheers,
Greg.
>
> Gr. Sim
>
>
> # Coding conventions
>
> ## Indentation
> Tabs are not used. Default indentation is 4 spaces.
>
> ## Other
> Contributors are advised to read
> <http://www.oracle.com/technetwork/java/codeconv-138413.html>
> and try to adhere as much as possible to these conventions.
>
> ## Older sources
> We do not actively search and reformat source files
> that are not formatted according to this convention.
>
> Tab stops are considered to be on 8 spaces interval.
Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/10/2010 11:34 PM, Gregg Wonderly wrote:
> Okay, this is good news, and I guess I just did not see this being
> added. I've turned on per project formatting for the Jini tree as "tabs
> are 8" and "indentation is 4" and that makes a huge difference in
> readability. So maybe I can just relax a bit about this issue.
I've added a small note about the tabstops. Everybody in agreement?
Gr. Sim
# Coding conventions
## Indentation
Tabs are not used. Default indentation is 4 spaces.
## Other
Contributors are advised to read
<http://www.oracle.com/technetwork/java/codeconv-138413.html>
and try to adhere as much as possible to these conventions.
## Older sources
We do not actively search and reformat source files
that are not formatted according to this convention.
Tab stops are considered to be on 8 spaces interval.
Re: Formatting of River Source Tree
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 12/9/2010 2:24 PM, Wade Chandler wrote:
> ----- Original Message ----
>
>> From: Gregg Wonderly<gr...@wonderly.org>
>> To: river-dev@incubator.apache.org
>> Cc: Patricia Shanahan<pa...@acm.org>
>> Sent: Thu, December 9, 2010 10:13:04 AM
>> Subject: Re: Formatting of River Source Tree
>>
>> On 12/8/2010 6:00 PM, Patricia Shanahan wrote:
>>> You should consider using an IDE such as Eclipse that supports
>>> project-specific settings. I'm surprised at any modern IDE not
>>> supporting that, because many people work on multiple projects that have
>>> different conventions.
>>
>> I use netbeans, and it does not have per project control. It does control tab
>>
>> expansion by content type of the file you are editing.
>>
>
> Later versions of NetBeans allow project level formatting Gregg. Look in your
> project properties under "Formatting". You can set the project to use project
> specific formatting there. Not near as flexible as VI in that regard though.
Okay, this is good news, and I guess I just did not see this being added. I've
turned on per project formatting for the Jini tree as "tabs are 8" and
"indentation is 4" and that makes a huge difference in readability. So maybe I
can just relax a bit about this issue.
Gregg Wonderly
Re: Formatting of River Source Tree
Posted by Wade Chandler <hw...@yahoo.com>.
----- Original Message ----
> From: Gregg Wonderly <gr...@wonderly.org>
> To: river-dev@incubator.apache.org
> Cc: Patricia Shanahan <pa...@acm.org>
> Sent: Thu, December 9, 2010 10:13:04 AM
> Subject: Re: Formatting of River Source Tree
>
> On 12/8/2010 6:00 PM, Patricia Shanahan wrote:
> > You should consider using an IDE such as Eclipse that supports
> > project-specific settings. I'm surprised at any modern IDE not
> > supporting that, because many people work on multiple projects that have
> > different conventions.
>
> I use netbeans, and it does not have per project control. It does control tab
>
> expansion by content type of the file you are editing.
>
Later versions of NetBeans allow project level formatting Gregg. Look in your
project properties under "Formatting". You can set the project to use project
specific formatting there. Not near as flexible as VI in that regard though.
Hope it helps,
Wade
==================
Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
Re: Formatting of River Source Tree
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 12/8/2010 6:00 PM, Patricia Shanahan wrote:
> Gregg Wonderly wrote:
>> I can get by in VI. But in an IDE it gets much harder to switch
>> between tabs and spaces. Just tabs means I can't edit code and type
>> tab without changing how they expand and what interval they expand
>> to. This is an IDE wide setting.
>
> Did you mean "Just spaces" rather than "Just tabs" above?
Yes, I did, sorry for the confusion.
>
>> So then when I am messing with my own code and "spaced" code, I have
>> to jump through all kinds of hoops in the end to not end up with a
>> mismash of tabbing.
>
> You should consider using an IDE such as Eclipse that supports
> project-specific settings. I'm surprised at any modern IDE not
> supporting that, because many people work on multiple projects that have
> different conventions.
I use netbeans, and it does not have per project control. It does control tab
expansion by content type of the file you are editing.
> No matter what choice we make, some of us are going to have to depend on
> project-specific settings because it's obvious we are not all using the
> same default settings in our IDEs.
>
>> Okay, enough said.
>
> Yes, I think we need to just make a decision and move on. This is the
> sort of thing that can be argued about for years without reaching a
> conclusion that satisfies everyone.
>
> Patricia
>
Re: Formatting of River Source Tree
Posted by Patricia Shanahan <pa...@acm.org>.
Gregg Wonderly wrote:
> I can get by in VI. But in an IDE it gets much harder to switch
> between tabs and spaces. Just tabs means I can't edit code and type
> tab without changing how they expand and what interval they expand
> to. This is an IDE wide setting.
Did you mean "Just spaces" rather than "Just tabs" above?
> So then when I am messing with my own code and "spaced" code, I have
> to jump through all kinds of hoops in the end to not end up with a
> mismash of tabbing.
You should consider using an IDE such as Eclipse that supports
project-specific settings. I'm surprised at any modern IDE not
supporting that, because many people work on multiple projects that have
different conventions.
No matter what choice we make, some of us are going to have to depend on
project-specific settings because it's obvious we are not all using the
same default settings in our IDEs.
> Okay, enough said.
Yes, I think we need to just make a decision and move on. This is the
sort of thing that can be argued about for years without reaching a
conclusion that satisfies everyone.
Patricia
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-12-10 10:44, Sim IJskes - QCG wrote:
> On 12/09/2010 10:34 AM, Tom Hobbs wrote:
>>> Standard no reformatting only commits.
>>
>> That, when I come across a poorly formated source file (or which there
>> are many) I can't do a reformat and commit? (And here I'm talking
>> about more than just tabs vs spaces). If so, I think that's possibly
>> a mistake, committing reformatting changes at that same time as
>> meaningful code changes can make reading a diff much harder.
>
> Maybe better phrased is: By default no reformatting-only contributions.
> What is necessary is necessary. So if you fix something but want to fix
> the layout first locally, please go ahead.
>
> Gr. Sim
Shall i draft a webpage in staging?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Patricia Shanahan <pa...@acm.org>.
Tom Hobbs wrote:
> Okay, I get it. I think.
>
> A mass re-formating of the entire source is definitely a waste of time
> and effort.
I agree.
>
> So does the following scenario meet this standard?
>
> - I want to make a meaningful change to Class A.
> - Class A is badly formatted.
> - I fix the formatting of Class A.
> - I commit Class A.
> - I make my meaningful change to Class A.
> - I commit Class A.
>
> The above process has served me well in the past.
I think this is a good process with one small change. During debug, I
sometimes have to keep visiting and studying a class that is not
necessarily the root cause of the bug. I would like to have the option of:
- I need to study Class A.
- Class A is badly formatted.
- I fix the formatting of Class A.
- I commit Class A.
- I make my meaningful change to Class B.
- I commit Class B.
In other words, don't go looking for classes to reformat, but if you
trip over a badly formatted class that is getting in the way, reformat
and commit it.
I do think general reformatting of a complete class should be a separate
commit, clearly labeled as reformatting.
>
> On Thu, Dec 9, 2010 at 9:44 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
>> On 12/09/2010 10:34 AM, Tom Hobbs wrote:
>>>> Standard no reformatting only commits.
>>> That, when I come across a poorly formated source file (or which there
>>> are many) I can't do a reformat and commit? (And here I'm talking
>>> about more than just tabs vs spaces). If so, I think that's possibly
>>> a mistake, committing reformatting changes at that same time as
>>> meaningful code changes can make reading a diff much harder.
>> Maybe better phrased is: By default no reformatting-only contributions.
>> What is necessary is necessary. So if you fix something but want to fix the
>> layout first locally, please go ahead.
>>
>> Gr. Sim
>>
>
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-12-10 11:00, Tom Hobbs wrote:
> Okay, I get it. I think.
>
> A mass re-formating of the entire source is definitely a waste of time
> and effort.
>
> So does the following scenario meet this standard?
>
> - I want to make a meaningful change to Class A.
> - Class A is badly formatted.
> - I fix the formatting of Class A.
> - I commit Class A.
> - I make my meaningful change to Class A.
> - I commit Class A.
Perfect!
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Tom Hobbs <tv...@googlemail.com>.
Okay, I get it. I think.
A mass re-formating of the entire source is definitely a waste of time
and effort.
So does the following scenario meet this standard?
- I want to make a meaningful change to Class A.
- Class A is badly formatted.
- I fix the formatting of Class A.
- I commit Class A.
- I make my meaningful change to Class A.
- I commit Class A.
The above process has served me well in the past.
On Thu, Dec 9, 2010 at 9:44 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 12/09/2010 10:34 AM, Tom Hobbs wrote:
>>>
>>> Standard no reformatting only commits.
>>
>> That, when I come across a poorly formated source file (or which there
>> are many) I can't do a reformat and commit? (And here I'm talking
>> about more than just tabs vs spaces). If so, I think that's possibly
>> a mistake, committing reformatting changes at that same time as
>> meaningful code changes can make reading a diff much harder.
>
> Maybe better phrased is: By default no reformatting-only contributions.
> What is necessary is necessary. So if you fix something but want to fix the
> layout first locally, please go ahead.
>
> Gr. Sim
>
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/09/2010 10:34 AM, Tom Hobbs wrote:
>> Standard no reformatting only commits.
>
> That, when I come across a poorly formated source file (or which there
> are many) I can't do a reformat and commit? (And here I'm talking
> about more than just tabs vs spaces). If so, I think that's possibly
> a mistake, committing reformatting changes at that same time as
> meaningful code changes can make reading a diff much harder.
Maybe better phrased is: By default no reformatting-only contributions.
What is necessary is necessary. So if you fix something but want to fix
the layout first locally, please go ahead.
Gr. Sim
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/09/2010 10:34 AM, Tom Hobbs wrote:
> I echo Patricia, +0.5 for option 1 for the same reasons.
>
> I like these two:
>> No plowing through source to convert all tabs into spaces (with the only intent of conversion)
>> No contribution will be refused based on indentation and tabs issues.
>
> But what does this mean?
I've worked in teams where this happened. It was not efficient. Just
saying that we create a standard here. Not a law. So if people find the
need to deviate, they can.
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Zsolt Kúti <la...@gmail.com>.
On Thu, 9 Dec 2010 14:04:26 -0500
Dennis Reedy <de...@gmail.com> wrote:
>
> On Dec 9, 2010, at 200PM, Sim IJskes - QCG wrote:
>
> > On 12/09/2010 06:37 PM, Christopher Dolan wrote:
> >> Yes, sorry, I replied to the wrong email... I meant to react to
> >> the proposal of:
> >>
> >> - I want to make a meaningful change to Class A.
> >> - Class A is badly formatted.
> >> - I fix the formatting of Class A.
> >> - I commit Class A.
> >> - I make my meaningful change to Class A.
> >> - I commit Class A.
> >>
> >> I think steps #3 and #4 are a bad idea. Your endorsement of that
> >
> > Do you object to the formatting or the intermediate commit? Do you
> > think the scope of the class is too big, should it be only the
> > method that is fixed? Or are you completely against reformatting?
> >
> > I think it is a bit too much to write 'we forbid', it is an adult
> > fixing the source, for free, shouldn't we allow a bit of freedom in
> > this case?
>
> I agree. If source is difficult to read and it can be improved by
> reformatting, then why not reformat and commit. Its on an as needed
> basis, after all.
Reformatting could cause problem if others work on the same
source file (potential large conflicts), so communication is needed
then to resolve the situation.
Keeping reading badly formatted sources requires mazochism :-)
Zsolt
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Dennis Reedy <de...@gmail.com>.
On Dec 9, 2010, at 200PM, Sim IJskes - QCG wrote:
> On 12/09/2010 06:37 PM, Christopher Dolan wrote:
>> Yes, sorry, I replied to the wrong email... I meant to react to the
>> proposal of:
>>
>> - I want to make a meaningful change to Class A.
>> - Class A is badly formatted.
>> - I fix the formatting of Class A.
>> - I commit Class A.
>> - I make my meaningful change to Class A.
>> - I commit Class A.
>>
>> I think steps #3 and #4 are a bad idea. Your endorsement of that
>
> Do you object to the formatting or the intermediate commit? Do you think the scope of the class is too big, should it be only the method that is fixed? Or are you completely against reformatting?
>
> I think it is a bit too much to write 'we forbid', it is an adult fixing the source, for free, shouldn't we allow a bit of freedom in this case?
I agree. If source is difficult to read and it can be improved by reformatting, then why not reformat and commit. Its on an as needed basis, after all.
Dennis
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/09/2010 06:37 PM, Christopher Dolan wrote:
> Yes, sorry, I replied to the wrong email... I meant to react to the
> proposal of:
>
> - I want to make a meaningful change to Class A.
> - Class A is badly formatted.
> - I fix the formatting of Class A.
> - I commit Class A.
> - I make my meaningful change to Class A.
> - I commit Class A.
>
> I think steps #3 and #4 are a bad idea. Your endorsement of that
Do you object to the formatting or the intermediate commit? Do you think
the scope of the class is too big, should it be only the method that is
fixed? Or are you completely against reformatting?
I think it is a bit too much to write 'we forbid', it is an adult fixing
the source, for free, shouldn't we allow a bit of freedom in this case?
Gr. Sim
RE: [VOTE] Re: Formatting of River Source Tree
Posted by Christopher Dolan <ch...@avid.com>.
Yes, sorry, I replied to the wrong email... I meant to react to the
proposal of:
- I want to make a meaningful change to Class A.
- Class A is badly formatted.
- I fix the formatting of Class A.
- I commit Class A.
- I make my meaningful change to Class A.
- I commit Class A.
I think steps #3 and #4 are a bad idea. Your endorsement of that
workflow in
http://mail-archives.apache.org/mod_mbox/incubator-river-dev/201012.mbox
/%3C4D00AB04.4050702@qcg.nl%3E
contradicts the "older sources" clause, I think.
Chris
-----Original Message-----
From: Sim IJskes - QCG [mailto:sim@qcg.nl]
Sent: Thursday, December 09, 2010 9:24 AM
To: river-dev@incubator.apache.org
Subject: Re: [VOTE] Re: Formatting of River Source Tree
On 09-12-10 16:11, Christopher Dolan wrote:
> and many (most?) of the files have a mix of both. So, I make the
> counter-proposal that it's too late to fix this without a lot of
> pointless code churn. I think we need to forbid formatting fixes that
> just change tabs to spaces or vice versa. Even when done as separate
> commits, those changes wreak havoc on diffs when trying to
troubleshoot
> regressions. I say developers just need to set their IDE to 8-chars
for
> tab for this project and live with it.
Doesn't the older sources clause cover your proposal in broad lines? Do
we need to be more specific?
Gr. Sim
Do you have r/o access to staging? In case you haven't:
# Coding conventions
## Indentation
Tabs are not used. Default indentation is 4 spaces.
## Other
Contributors are advised to read
<http://www.oracle.com/technetwork/java/codeconv-138413.html>
and try to adhere as much as possible to these conventions.
## Older sources
We do not actively search and reformat source files
that are not formatted according to this convention.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-12-10 16:11, Christopher Dolan wrote:
> and many (most?) of the files have a mix of both. So, I make the
> counter-proposal that it's too late to fix this without a lot of
> pointless code churn. I think we need to forbid formatting fixes that
> just change tabs to spaces or vice versa. Even when done as separate
> commits, those changes wreak havoc on diffs when trying to troubleshoot
> regressions. I say developers just need to set their IDE to 8-chars for
> tab for this project and live with it.
Doesn't the older sources clause cover your proposal in broad lines? Do
we need to be more specific?
Gr. Sim
Do you have r/o access to staging? In case you haven't:
# Coding conventions
## Indentation
Tabs are not used. Default indentation is 4 spaces.
## Other
Contributors are advised to read
<http://www.oracle.com/technetwork/java/codeconv-138413.html>
and try to adhere as much as possible to these conventions.
## Older sources
We do not actively search and reformat source files
that are not formatted according to this convention.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
RE: [VOTE] Re: Formatting of River Source Tree
Posted by Christopher Dolan <ch...@avid.com>.
I did a quick search of the source code of River 2.1.0 (it's what I had
handy)
*.java, number of tabs: 123176
*.java, number of 4-spaces: 192828
*.xml, number of tabs: 10366
*.xml, number of 4-spaces: 6918
and many (most?) of the files have a mix of both. So, I make the
counter-proposal that it's too late to fix this without a lot of
pointless code churn. I think we need to forbid formatting fixes that
just change tabs to spaces or vice versa. Even when done as separate
commits, those changes wreak havoc on diffs when trying to troubleshoot
regressions. I say developers just need to set their IDE to 8-chars for
tab for this project and live with it.
That said, I think it's fine to have a tabs-only or spaces-only policy
for *new* code. The ffmpeg project, as an example, has a VERY strict
checkin policy that says whitespace has to be perfect before they accept
a patch. That's the only way to get a clean source tree with a lot of
developers.
Chris
-----Original Message-----
From: Sim IJskes - QCG [mailto:sim@qcg.nl]
Sent: Thursday, December 09, 2010 8:57 AM
To: river-dev@incubator.apache.org
Subject: Re: [VOTE] Re: Formatting of River Source Tree
On 09-12-10 15:49, Sim IJskes - QCG wrote:
> http://river.staging.apache.org/river/coding.html
BTW, i really hate some of the coding conventions in "Code Conventions
for the Java Programming Language". I've written and maintained software
and if it is clear, then its ok. I can read other ones code, and write
according to my own. I see no problem to have multiple styles in a
single file.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-12-10 15:49, Sim IJskes - QCG wrote:
> http://river.staging.apache.org/river/coding.html
BTW, i really hate some of the coding conventions in "Code Conventions
for the Java Programming Language". I've written and maintained software
and if it is clear, then its ok. I can read other ones code, and write
according to my own. I see no problem to have multiple styles in a
single file.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-12-10 16:24, Gregg Wonderly wrote:
> I have a long history with VI. I found the '%' abbreviation for '1,$' in
> the source code (we had a source license in college), never saw it in
> any documentation we had for V7 Unix. When VMS first included TPU (VMS
> 4.x), I set down and wrote a rather complete implementation of VI in TPU
> that I published on usenet as VITPU back in the mid 1980's. My brain is
> wired...
Good old VMS, that brings back memories. Semicolons, BITNET, SIMTEL.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Tom Hobbs <tv...@googlemail.com>.
Actually I was thinking of a Haskell port.
True story: One of my other projects is trying to write a Haskell
interface to a different Object Space - http://www.flyobjectspace.com/
On Thu, Dec 9, 2010 at 3:02 PM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 09-12-10 15:59, Sim IJskes - QCG wrote:
>>>
>>> Next up, Vi vs Emacs!
>
> We could also build a river implementation in lisp. Cant we?
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-12-10 15:59, Sim IJskes - QCG wrote:
>> Next up, Vi vs Emacs!
We could also build a river implementation in lisp. Cant we?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Tom Hobbs <tv...@googlemail.com>.
The only thing I like about NetBeans (other than I don't have to use
it anymore... ;-) Is that there is a free vi plugin for it
(http://jvi.sourceforge.net/).
Eclipse has a similar plugin, but it is not free. It's cheap, but not free.
On Thu, Dec 9, 2010 at 2:59 PM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 09-12-10 15:56, Tom Hobbs wrote:
>>
>> Looks good to me.
>>
>> You can tell we're shaping up into to proper project team now 'cause
>> the amount of time we've argued over tabs vs spaces! :-)
>
> You sound like a true Chair.
>
>> Next up, Vi vs Emacs!
>>
>> P.S. Gregg, it's great to find another Vi user, I was beginning to
>> think I was all on my own!
>
> meep, meep, me too! But i use netbeans to develop.
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-12-10 15:56, Tom Hobbs wrote:
> Looks good to me.
>
> You can tell we're shaping up into to proper project team now 'cause
> the amount of time we've argued over tabs vs spaces! :-)
You sound like a true Chair.
> Next up, Vi vs Emacs!
>
> P.S. Gregg, it's great to find another Vi user, I was beginning to
> think I was all on my own!
meep, meep, me too! But i use netbeans to develop.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 12/9/2010 8:56 AM, Tom Hobbs wrote:
> Looks good to me.
>
> You can tell we're shaping up into to proper project team now 'cause
> the amount of time we've argued over tabs vs spaces! :-)
>
> Next up, Vi vs Emacs!
>
> P.S. Gregg, it's great to find another Vi user, I was beginning to
> think I was all on my own!
I have a long history with VI. I found the '%' abbreviation for '1,$' in the
source code (we had a source license in college), never saw it in any
documentation we had for V7 Unix. When VMS first included TPU (VMS 4.x), I set
down and wrote a rather complete implementation of VI in TPU that I published on
usenet as VITPU back in the mid 1980's. My brain is wired...
Gregg
> On Thu, Dec 9, 2010 at 2:49 PM, Sim IJskes - QCG<si...@qcg.nl> wrote:
>>>> Proposal:
>>>>
>>>> Standard indent is 4 spaces.
>>>> Standard we use no tabs.
>>>> No plowing through source to convert all tabs into spaces (with the only
>>>> intent of conversion)
>>>> No contribution will be refused based on indentation and tabs issues.
>>>> Standard no reformatting only commits.
>>>>
>>>> Standard meaning standard. Not rule.
>>>>
>>>> Gr. Sim
>>>>
>>
>> http://river.staging.apache.org/river/coding.html
>>
>>
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>>
>
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Tom Hobbs <tv...@googlemail.com>.
Looks good to me.
You can tell we're shaping up into to proper project team now 'cause
the amount of time we've argued over tabs vs spaces! :-)
Next up, Vi vs Emacs!
P.S. Gregg, it's great to find another Vi user, I was beginning to
think I was all on my own!
On Thu, Dec 9, 2010 at 2:49 PM, Sim IJskes - QCG <si...@qcg.nl> wrote:
>>> Proposal:
>>>
>>> Standard indent is 4 spaces.
>>> Standard we use no tabs.
>>> No plowing through source to convert all tabs into spaces (with the only
>>> intent of conversion)
>>> No contribution will be refused based on indentation and tabs issues.
>>> Standard no reformatting only commits.
>>>
>>> Standard meaning standard. Not rule.
>>>
>>> Gr. Sim
>>>
>
> http://river.staging.apache.org/river/coding.html
>
>
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
>> Proposal:
>>
>> Standard indent is 4 spaces.
>> Standard we use no tabs.
>> No plowing through source to convert all tabs into spaces (with the only
>> intent of conversion)
>> No contribution will be refused based on indentation and tabs issues.
>> Standard no reformatting only commits.
>>
>> Standard meaning standard. Not rule.
>>
>> Gr. Sim
>>
http://river.staging.apache.org/river/coding.html
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Tom Hobbs <tv...@googlemail.com>.
I echo Patricia, +0.5 for option 1 for the same reasons.
I like these two:
> No plowing through source to convert all tabs into spaces (with the only intent of conversion)
> No contribution will be refused based on indentation and tabs issues.
But what does this mean?
> Standard no reformatting only commits.
That, when I come across a poorly formated source file (or which there
are many) I can't do a reformat and commit? (And here I'm talking
about more than just tabs vs spaces). If so, I think that's possibly
a mistake, committing reformatting changes at that same time as
meaningful code changes can make reading a diff much harder.
Other than that, +1 on Sim's proposal.
The outcome of this needs to make it onto the website as well. I
would suggest that the "Code Conventions" page includes the outcome of
this vote, a link to the mail archive, and a link to the Sun-specified
coding standards. I don't see the value in trying to enforce any
other code convention.
On Thu, Dec 9, 2010 at 7:50 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 12/09/2010 03:15 AM, Patricia Shanahan wrote:
>>
>> Option 1: An indentation step is four spaces.
>
> +1
>
> Proposal:
>
> Standard indent is 4 spaces.
> Standard we use no tabs.
> No plowing through source to convert all tabs into spaces (with the only
> intent of conversion)
> No contribution will be refused based on indentation and tabs issues.
> Standard no reformatting only commits.
>
> Standard meaning standard. Not rule.
>
> Gr. Sim
>
Re: [VOTE] Re: Formatting of River Source Tree
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 12/09/2010 03:15 AM, Patricia Shanahan wrote:
>
> Option 1: An indentation step is four spaces.
+1
Proposal:
Standard indent is 4 spaces.
Standard we use no tabs.
No plowing through source to convert all tabs into spaces (with the only
intent of conversion)
No contribution will be refused based on indentation and tabs issues.
Standard no reformatting only commits.
Standard meaning standard. Not rule.
Gr. Sim
[VOTE] Re: Formatting of River Source Tree
Posted by Patricia Shanahan <pa...@acm.org>.
Peter Firmstone wrote:
> Gregg Wonderly wrote:
...
>> So then when I am messing with my own code and "spaced" code, I have
>> to jump through all kinds of hoops in the end to not end up with a
>> mismash of tabbing.
>>
>> Okay, enough said.
>>
>> Gregg Wonderly
>>
>>
> I actually changed to tabs the first time you suggested it, it seemed
> like a good suggestion, I guess Programmers can be a finicky bunch.
>
> Never mind, should I change back to spaces now?
I think everything worth saying about this has been said, and we need to
make a decision one way or another and stick with it. I prefer spaces,
but feel far more strongly in favor of a common convention. I suggest we
vote between two options, unless someone wants to strongly push
something else:
Option 1: An indentation step is four spaces.
Option 2: An indentation step is a single tab.
I'm +0.5 for option 1.
It's only 0.5 because I'm more concerned about reaching consensus than
the actual choice, and I do have access to project-specific settings in
my preferred IDE.
Patricia
Re: Formatting of River Source Tree
Posted by Peter Firmstone <ji...@zeus.net.au>.
Gregg Wonderly wrote:
> On 12/5/2010 12:26 PM, Patricia Shanahan wrote:
>> On 12/5/2010 10:09 AM, Gregg Wonderly wrote:
>>> I understand that many people have differing problems with just tabs.
>>> All of the printing, cating and screen dumping issues are most likely
>>> in an environment where you can use
>>>
>>> pr -te 4 ... | more
>>
>> This does not really help with copy-paste into e-mail.
>
> I just open file in the vi editor and type "%s/^t/ /g" copy the
> text and paste it into the mail message. I've just always done this
> kind of thing because it is so easy to do.
>
>>> Many other out if the IDE/editor issues can be solved with something
>>> similar.
>>>
>>> My main issue is, about in the editor/IDE. Iff there are just tabs,
>>> then anything that your IDE does with tab expansion does not hide
>>> indentation.
>>>
>>> Iff there are only spaces, then while you are viewing, you won't see
>>> anything odd. But when you start editing, then you have to have your
>>> tabs set to the same number of spaces as the source file. Of you
>>> expand tabs to spaces all us well. If you don't, then then next
>>> person to view the file with a different tab setting will have a
>>> nightmare.
>>>
>>> Sure, you have to do tabs only or spaces only everywhere for anything
>>> to work. With tabs you lose the problem in the editor of needing the
>>> same expansion factor.
>>
>> Don't you need matching set-up either way? Tab-only with the
>> indentation to 4
>> spaces, and the tabs to 2 would be just as bad as space only with the
>> wrong
>> number of spaces.
>
> No, I never put "text" that is not code after tabs. In comments I put
> spaces and I usually never (but have on occasion) create complex
> layouts of trailing aligned text to the right of code without using
> spaces instead of tabs.
>
>> The good news about spaces is that the code will display with reasonable
>> indentation in *all* environments, including e.g. quotes in e-mail,
>> regardless
>> of the choice of e-mail client.
>
> Okay, display is fine with tabs, but I am talking specifically about
> code that everyone has to edit (open source multiple commiters). When
> I worked at AT&T, module owners did not always "edit" code in their
> modules, they were the approval gate. The use of tabs only made it
> possible for everyone to use different tab settings. We had people
> with different screen resolutions, different width textual screens,
> different computers/terminals etc. People needed to be able to adjust
> tab expansion of code on a wim so that they could look at complex
> indentations of very deep in-lined code. I'd regularly type ":set
> ts=2 sw=2" in vi to look at stuff that needed to be looked at this way.
>
> With just spaces, you can never do that sort of thing in most editors
> trivially. In VI, you can of course do ":set ts=X sw=X" to whatever
> the expansion was in spaces then type 1G>G followed by 1G<G followed
> by ":set ts=4 sw=4" to see the code in 4 character tabs.
>
> Somehow I'm sure that most of you have completely different
> experiences and really value your spaces. I'll stop going on about
> this, but I just wanted to stress that I have spent a lot of time
> using just tabs (25+ years) and I've always wondered why people are so
> convinced about just spaces. I've heard a lot of explanations, but
> most of them are about printing, viewing and "catting".
>
> I've always used the VI editor for the same 25+ years and it has such
> easy control and expansion of spaces vs tabs, that I just always deal
> with whatever I come up against. In mixed tabs and spaces, I do
> "1G!Gp4 -te 8 % | more" and then the above ":set ts=8 sw=8", !G>G,
> 1G<G to switch to leading tabs, and then ":set ts=4 sw=4" to switch to
> 4 character tabs, which I usually use.
>
> I can get by in VI. But in an IDE it gets much harder to switch
> between tabs and spaces. Just tabs means I can't edit code and type
> tab without changing how they expand and what interval they expand
> to. This is an IDE wide setting.
>
> So then when I am messing with my own code and "spaced" code, I have
> to jump through all kinds of hoops in the end to not end up with a
> mismash of tabbing.
>
> Okay, enough said.
>
> Gregg Wonderly
>
>
I actually changed to tabs the first time you suggested it, it seemed
like a good suggestion, I guess Programmers can be a finicky bunch.
Never mind, should I change back to spaces now?
Peter.
Re: Formatting of River Source Tree
Posted by Niclas Hedhman <ni...@hedhman.org>.
Gregg,
I don't think anyone questions your ability to make it work well for
you. If it wasn't, then you and N% of the developers would continue
with it.
I think the strongest argument in favor of spaces are simply; More
people/projects fuck up with tabs. Tabs users are "annoyed" over space
usage, but Space users not only screw up their own experience, but for
everyone else as well on every commit.
Cheers
Niclas
On Thu, Dec 9, 2010 at 7:23 AM, Gregg Wonderly <gr...@wonderly.org> wrote:
> On 12/5/2010 12:26 PM, Patricia Shanahan wrote:
>>
>> On 12/5/2010 10:09 AM, Gregg Wonderly wrote:
>>>
>>> I understand that many people have differing problems with just tabs.
>>> All of the printing, cating and screen dumping issues are most likely
>>> in an environment where you can use
>>>
>>> pr -te 4 ... | more
>>
>> This does not really help with copy-paste into e-mail.
>
> I just open file in the vi editor and type "%s/^t/ /g" copy the text and
> paste it into the mail message. I've just always done this kind of thing
> because it is so easy to do.
>
>>> Many other out if the IDE/editor issues can be solved with something
>>> similar.
>>>
>>> My main issue is, about in the editor/IDE. Iff there are just tabs,
>>> then anything that your IDE does with tab expansion does not hide
>>> indentation.
>>>
>>> Iff there are only spaces, then while you are viewing, you won't see
>>> anything odd. But when you start editing, then you have to have your
>>> tabs set to the same number of spaces as the source file. Of you
>>> expand tabs to spaces all us well. If you don't, then then next
>>> person to view the file with a different tab setting will have a
>>> nightmare.
>>>
>>> Sure, you have to do tabs only or spaces only everywhere for anything
>>> to work. With tabs you lose the problem in the editor of needing the
>>> same expansion factor.
>>
>> Don't you need matching set-up either way? Tab-only with the indentation
>> to 4
>> spaces, and the tabs to 2 would be just as bad as space only with the
>> wrong
>> number of spaces.
>
> No, I never put "text" that is not code after tabs. In comments I put
> spaces and I usually never (but have on occasion) create complex layouts of
> trailing aligned text to the right of code without using spaces instead of
> tabs.
>
>> The good news about spaces is that the code will display with reasonable
>> indentation in *all* environments, including e.g. quotes in e-mail,
>> regardless
>> of the choice of e-mail client.
>
> Okay, display is fine with tabs, but I am talking specifically about code
> that everyone has to edit (open source multiple commiters). When I worked
> at AT&T, module owners did not always "edit" code in their modules, they
> were the approval gate. The use of tabs only made it possible for everyone
> to use different tab settings. We had people with different screen
> resolutions, different width textual screens, different computers/terminals
> etc. People needed to be able to adjust tab expansion of code on a wim so
> that they could look at complex indentations of very deep in-lined code.
> I'd regularly type ":set ts=2 sw=2" in vi to look at stuff that needed to
> be looked at this way.
>
> With just spaces, you can never do that sort of thing in most editors
> trivially. In VI, you can of course do ":set ts=X sw=X" to whatever the
> expansion was in spaces then type 1G>G followed by 1G<G followed by ":set
> ts=4 sw=4" to see the code in 4 character tabs.
>
> Somehow I'm sure that most of you have completely different experiences and
> really value your spaces. I'll stop going on about this, but I just wanted
> to stress that I have spent a lot of time using just tabs (25+ years) and
> I've always wondered why people are so convinced about just spaces. I've
> heard a lot of explanations, but most of them are about printing, viewing
> and "catting".
>
> I've always used the VI editor for the same 25+ years and it has such easy
> control and expansion of spaces vs tabs, that I just always deal with
> whatever I come up against. In mixed tabs and spaces, I do "1G!Gp4 -te 8 %
> | more" and then the above ":set ts=8 sw=8", !G>G, 1G<G to switch to leading
> tabs, and then ":set ts=4 sw=4" to switch to 4 character tabs, which I
> usually use.
>
> I can get by in VI. But in an IDE it gets much harder to switch between
> tabs and spaces. Just tabs means I can't edit code and type tab without
> changing how they expand and what interval they expand to. This is an IDE
> wide setting.
>
> So then when I am messing with my own code and "spaced" code, I have to jump
> through all kinds of hoops in the end to not end up with a mismash of
> tabbing.
>
> Okay, enough said.
>
> Gregg Wonderly
>
>
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
Re: Formatting of River Source Tree
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 12/5/2010 12:26 PM, Patricia Shanahan wrote:
> On 12/5/2010 10:09 AM, Gregg Wonderly wrote:
>> I understand that many people have differing problems with just tabs.
>> All of the printing, cating and screen dumping issues are most likely
>> in an environment where you can use
>>
>> pr -te 4 ... | more
>
> This does not really help with copy-paste into e-mail.
I just open file in the vi editor and type "%s/^t/ /g" copy the text and
paste it into the mail message. I've just always done this kind of thing
because it is so easy to do.
>> Many other out if the IDE/editor issues can be solved with something
>> similar.
>>
>> My main issue is, about in the editor/IDE. Iff there are just tabs,
>> then anything that your IDE does with tab expansion does not hide
>> indentation.
>>
>> Iff there are only spaces, then while you are viewing, you won't see
>> anything odd. But when you start editing, then you have to have your
>> tabs set to the same number of spaces as the source file. Of you
>> expand tabs to spaces all us well. If you don't, then then next
>> person to view the file with a different tab setting will have a
>> nightmare.
>>
>> Sure, you have to do tabs only or spaces only everywhere for anything
>> to work. With tabs you lose the problem in the editor of needing the
>> same expansion factor.
>
> Don't you need matching set-up either way? Tab-only with the indentation to 4
> spaces, and the tabs to 2 would be just as bad as space only with the wrong
> number of spaces.
No, I never put "text" that is not code after tabs. In comments I put spaces
and I usually never (but have on occasion) create complex layouts of trailing
aligned text to the right of code without using spaces instead of tabs.
> The good news about spaces is that the code will display with reasonable
> indentation in *all* environments, including e.g. quotes in e-mail, regardless
> of the choice of e-mail client.
Okay, display is fine with tabs, but I am talking specifically about code that
everyone has to edit (open source multiple commiters). When I worked at AT&T,
module owners did not always "edit" code in their modules, they were the
approval gate. The use of tabs only made it possible for everyone to use
different tab settings. We had people with different screen resolutions,
different width textual screens, different computers/terminals etc. People
needed to be able to adjust tab expansion of code on a wim so that they could
look at complex indentations of very deep in-lined code. I'd regularly type
":set ts=2 sw=2" in vi to look at stuff that needed to be looked at this way.
With just spaces, you can never do that sort of thing in most editors trivially.
In VI, you can of course do ":set ts=X sw=X" to whatever the expansion was in
spaces then type 1G>G followed by 1G<G followed by ":set ts=4 sw=4" to see the
code in 4 character tabs.
Somehow I'm sure that most of you have completely different experiences and
really value your spaces. I'll stop going on about this, but I just wanted to
stress that I have spent a lot of time using just tabs (25+ years) and I've
always wondered why people are so convinced about just spaces. I've heard a lot
of explanations, but most of them are about printing, viewing and "catting".
I've always used the VI editor for the same 25+ years and it has such easy
control and expansion of spaces vs tabs, that I just always deal with whatever I
come up against. In mixed tabs and spaces, I do "1G!Gp4 -te 8 % | more" and
then the above ":set ts=8 sw=8", !G>G, 1G<G to switch to leading tabs, and then
":set ts=4 sw=4" to switch to 4 character tabs, which I usually use.
I can get by in VI. But in an IDE it gets much harder to switch between tabs
and spaces. Just tabs means I can't edit code and type tab without changing how
they expand and what interval they expand to. This is an IDE wide setting.
So then when I am messing with my own code and "spaced" code, I have to jump
through all kinds of hoops in the end to not end up with a mismash of tabbing.
Okay, enough said.
Gregg Wonderly
Re: Formatting of River Source Tree
Posted by Patricia Shanahan <pa...@acm.org>.
On 12/5/2010 10:09 AM, Gregg Wonderly wrote:
> I understand that many people have differing problems with just tabs.
> All of the printing, cating and screen dumping issues are most likely
> in an environment where you can use
>
> pr -te 4 ... | more
This does not really help with copy-paste into e-mail.
> Many other out if the IDE/editor issues can be solved with something
> similar.
>
> My main issue is, about in the editor/IDE. Iff there are just tabs,
> then anything that your IDE does with tab expansion does not hide
> indentation.
>
> Iff there are only spaces, then while you are viewing, you won't see
> anything odd. But when you start editing, then you have to have your
> tabs set to the same number of spaces as the source file. Of you
> expand tabs to spaces all us well. If you don't, then then next
> person to view the file with a different tab setting will have a
> nightmare.
>
> Sure, you have to do tabs only or spaces only everywhere for anything
> to work. With tabs you lose the problem in the editor of needing the
> same expansion factor.
Don't you need matching set-up either way? Tab-only with the indentation
to 4 spaces, and the tabs to 2 would be just as bad as space only with
the wrong number of spaces.
The good news about spaces is that the code will display with reasonable
indentation in *all* environments, including e.g. quotes in e-mail,
regardless of the choice of e-mail client.
Patricia
Re: Formatting of River Source Tree
Posted by Gregg Wonderly <ge...@cox.net>.
I understand that many people have differing problems with just tabs. All of the printing, cating and screen dumping issues are most likely in an environment where you can use
pr -te 4 ... | more
Many other out if the IDE/editor issues can be solved with something similar.
My main issue is, about in the editor/IDE. Iff there are just tabs, then anything that your IDE does with tab expansion does not hide indentation.
Iff there are only spaces, then while you are viewing, you won't see anything odd. But when you start editing, then you have to have your tabs set to the same number of spaces as the source file. Of you expand tabs to spaces all us well. If you don't, then then next person to view the file with a different tab setting will have a nightmare.
Sure, you have to do tabs only or spaces only everywhere for anything to work. With tabs you lose the problem in the editor of needing the same expansion factor.
Gregg
Sent from my iPhone
On Dec 4, 2010, at 10:26 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> I have some issues around tabs;
>
> 1. There are more than one "use tabs" convention out there;
> a. One tab for an indentation.
> b. Tab onto next 8 character modulo. (Example; many JDK files)
>
> 2. For 1a, when catting a source file in the console, it becomes
> unreadable due to the 8 character expansion that happens there.
> For 1b. It becomes totally unreadable if you don't have your tab
> expansion set to 8 characters.
>
> 3. Some (not all) projects that claim to use tabs, don't enforce it,
> so unless you are actually using the same as everyone else,
> indentation is buggered.
>
>
> So the difference between theory and practice is that in theory there
> is no difference between theory and practice, but in practice there
> is.
>
>
> But I will not get involved in the flamewar that normally follows when
> this is brought up. ;-)
>
>
> Cheers
>
> On Thu, Dec 2, 2010 at 10:40 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
>> As I've said here before and elsewhere, I really feel that tabs only is the
>> most beneficial indentation to use. The reason is that it allows people who
>> use odd tab intervals to still see things and use their tab key while
>> editing without having to change their IDE settings while editing.
>>
>> Sun has an old formatting document that discusses using spaces only, and
>> netbeans does this by default. The biggest issue for me, of course, is that
>> I use 4 character tab expansion and tabs only in all of my development.
>>
>> In an open source world, all tabs is really the only thing that provides the
>> most flexibility it seems to me.
>>
>> Gregg Wonderly
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
Re: Formatting of River Source Tree
Posted by Niclas Hedhman <ni...@hedhman.org>.
I have some issues around tabs;
1. There are more than one "use tabs" convention out there;
a. One tab for an indentation.
b. Tab onto next 8 character modulo. (Example; many JDK files)
2. For 1a, when catting a source file in the console, it becomes
unreadable due to the 8 character expansion that happens there.
For 1b. It becomes totally unreadable if you don't have your tab
expansion set to 8 characters.
3. Some (not all) projects that claim to use tabs, don't enforce it,
so unless you are actually using the same as everyone else,
indentation is buggered.
So the difference between theory and practice is that in theory there
is no difference between theory and practice, but in practice there
is.
But I will not get involved in the flamewar that normally follows when
this is brought up. ;-)
Cheers
On Thu, Dec 2, 2010 at 10:40 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
> As I've said here before and elsewhere, I really feel that tabs only is the
> most beneficial indentation to use. The reason is that it allows people who
> use odd tab intervals to still see things and use their tab key while
> editing without having to change their IDE settings while editing.
>
> Sun has an old formatting document that discusses using spaces only, and
> netbeans does this by default. The biggest issue for me, of course, is that
> I use 4 character tab expansion and tabs only in all of my development.
>
> In an open source world, all tabs is really the only thing that provides the
> most flexibility it seems to me.
>
> Gregg Wonderly
>
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug