Indenting code?

Kelly O'Hair kelly.ohair at oracle.com
Fri Sep 14 19:34:47 UTC 2012


On automatic indenting...  just an experience that might be helpful and some observations

I have used NetBeans when working on JPRT since 2006 at least, updating to each new NetBeans as it came out.
The "Format" feature is a fantastic feature, but it is a constantly changing feature as it adds features or new options
every time you tell NetBeans to "Format" it could change the file even though it had  been Formatted in a previous
version. In addition, the default settings and your project settings on thing like 'spaces in if expressions' or whatever
can change, and you would have to re-Format all your files if you wanted that new style.
The source style and format options are a very personal preference

So I only run "Format" when I am making significant changes to a file, BUT, even that can be very painful, if the
file had not been worked on for a long time, the whitespace changes so overwhelm the diff or webrev that it is very
hard to see the critical changes in the source file. Telling diff to ignore whitespace changes helps, but at least with
NetBeans, "Format" will add newlines when you do "Format", so the noise can be significant.

Now I have been pretty much the singular person working on this source, so the impact isn't bad, BUT, when you
have multiple people working on the same sources, over a long period of time, that kind of whitespace
change would be a significant problem.
So it's a fantastic feature, but I am just not sure how it fits into a large multiple person project.

---

When we started OpenJDK we did a purge of TAB characters from all the sources and the jcheck extension
protects us from TAB characters ever coming back in. So in a sense we have some whitespace enforcement.

If we had a well defined formatter tool that we told people they must use, I suppose jcheck could enforce it's use
by refusing any changeset where the source hasn't been "properly" formatted.
But getting a whole bunch of different tools to do the same formatting? That seems like an exercise in futility.

Automated source changes without a human review has always been considered dangerous.

Getting everyone to what "proper" is and agree to using that one formatting tool might be a bit like herding cats though. :^(


What ever happened to that vision of storing ast's  that the source code gets derived from? ;^)

-kto

On Sep 14, 2012, at 11:17 AM, Jim Gish wrote:

> 
> On 09/14/2012 01:36 PM, John Zavgren wrote:
>> Good summary, Jim. Thanks.
>> 
>> All I was suggesting is that we should be aware that a few simple command line tools can be configured to automatically format a file before we create a webrev image.
>> 
> I think the tricky thing here, based on what Alan & I said earlier, is that the tools can massage the whole file.  I don't know of tools that have rules like that.  Anyone else?
> 
> Jim
>> I use "indent -i4 -bli4 fubar.java". Or if I need to format a section of a non conforming file, I open it in emacs, select the region then hit the tab key. indent is especially useful because it will convert a sows ear into a silk purse.
>> 
>> I didn't intend to start a discussion about various IDEs, although they ought to be configured correctly too.
>> 
>> If I know the rules for massaging code (do they exist?), the I can post the configurations for various tools (vi, emacs, indent, eclipse, netbeans, etc.) on one of our wikis, and no one needs to worry about this anymore. Maybe they're already there?
>> 
>> John
>> 
>> 
>> ----- Original Message -----
>> From: jim.gish at oracle.com
>> To: chris.hegarty at oracle.com
>> Cc: discuss at openjdk.java.net, net-dev at openjdk.java.net
>> Sent: Friday, September 14, 2012 1:24:06 PM GMT -05:00 US/Canada Eastern
>> Subject: Re: Indenting code?
>> 
>> While it is true that NB and Eclipse and other IDEs offer auto formatting and that will suit some us, I also no that there are some amongst us who still use emacs and vi and possibly other non-IDE editors.  The first thing to agree on is what standard are we coding to.  I had assumed it was the old Sun Java coding standards ( http://www.oracle.com/technetwork/java/codeconv-138413.html)
>> 
>> Is that the case?
>> 
>> If not, I suggest that we /don't /open this up to a full-fledged discussion of what the standard should be. I've been involved in far too many such religious debates over the years that end up reminding me of the famous Belushi-esque food fight scene from Animal House.  Instead, if any question on any one individual point comes up, we look at the predominate approach in the existing code and use that.
>> 
>> As Alan points out, local consistency is important to maintain.  In the unlikely event that an entire piece of code is rewritten, then it's ok to bring it up to the current standard, otherwise don't mess with it.  In other words, there are more important things to consider than whether any one piece of code meets the standard.  Although that would be ideal, we do have to consider the consequences of major formatting changes, since those will impact the ease of interpreting diffs, and far more significant, ability to manage merging.
>> 
>> If we agree that the old Sun Java coding standards are what we /are mostly/ using, then we can identify formatting templates for the major IDEs, and other tools as needed.
>> 
>> ....Jim
>> 
>> Also, this is broader than net-dev, so I'm moving the discussion to discuss at openjdk.java.net. Please respond there.
>> On 09/14/2012 12:27 PM, Chris Hegarty wrote:
>> 
>>    On 14/09/12 12:20, Alan Bateman wrote:
>> 
>>        On 14/09/2012 01:21, Brad Wetmore wrote:
>> 
>>            Netbean's automatic formatting does a pretty good job with
>>            new code.
>>            However, I think the general advice is to not change
>>            existing code
>>            just because.  When you're dealing with multiple release
>>            families, it
>>            makes the merges much more difficult.
>> 
>>            Brad
>> 
>>        One think that Paul Sandoz suggested recently is that we
>>        should have a
>>        NB template that folks can use to avoid some
>>        discussions/debates on
>>        styles. It would be great for someone to run with that, the
>>        hard part is
>>        of course that it will be impossible to get agreement.
>>        Personally I find
>>        NB's defaults okay but there are several cases where its
>>        indenting is
>>        horrible.
>> 
>> 
>>    I did play with NB somewhat trying to get it follow, exactly, the
>>    preferred style in some areas of the JDK code. I was able to get
>>    it close, or at least better than the default, but I don't believe
>>    it is possible to get it to do exactly what we want.
>> 
>>    -Chris.
>> 
>>        Anyway, the main advice I think is to keep things locally
>>        consistent
>>        where possible. Also major refactoring or formatting in a bug
>>        fix is a
>>        royal pain for reviewers.
>> 
>>        -Alan
>> 
>> 
>> -- 
>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>> Oracle Java Platform Group | Core Libraries Team
>> 35 Network Drive
>> Burlington, MA 01803
>> jim.gish at oracle.com
> 
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
> 




More information about the discuss mailing list