CodingConventionsComments.Imported @ jos.sf.net

Here's my take on the two issues presented so far.

A) I think the former looks more compact and preserves whitespace for more important uses. Indentation already sets off the code in the block, and TOO much whitespace (to me, at least) makes things hard to find when scanning a source file.

B) I think there's more important issues with applying a Hungarian-style convention here. Although I like the concept, we need to consider...

That differs dramatically from the core java API. We would have 2 competing naming conventions, one for standard java and one for JOS. It could be argued that it would help to tell when code is java/JOS, but I think it may just get confusing.
A convention would have to be adopted for other classes, unless we wanted to just have them follow a different naming convention. If I derive a class from LayoutManager called RandomLayoutManager to place components randomly on the screen, should I call an instance of it rlmLayout, or what?
Potential to get "behind." What if a central variable changes from an int to a float for some reason. Can we guarantee someone has the patience to change the name in every place that it is used in the entire project?

We could develop a more meaning-oriented, more natural language convention and fix the above problems. For instance, decide to call index variable indexVarName, boolean's isVarName, etc. I'm still not so sure about it, though.

-ChrisSmith

Re:B) What naming system exists in Sun core Java api? Maybe I just missed it somehow? :) -%BK%

Okay. Revise above to read "... 2 competing naming conventions (or lack thereof)..." -ChrisSmith

Isn't the __purpose__ of HungarianNotation to identify types in weakly typed language?

If we have to use them, I vote for the ones used by the VM, just lowercased. Thus:

__a__ object (don't ask me, I don't know)
__b__ byte
__c__ char
__d__ double
__f__ float
__i__ int
__j__ long
__s__ short
__z__ boolean

--BillRehm

Where is this documented? And why ever is it called Hungarian? -BK

What about the naming convention for Classes, and specifically for Interfaces. Should we prefix interface defintions with the letter 'I' or just give them names that end in 'able' (like the Java API?). -SimonSpringall

Netscape recently released their own Java coding conventions, and I think most of them are really good. I disagree with their use of tabs that are only 2 spaces, and the fact that they aren't standardizing brace styles, but it's a start:

http://developer.netscape.com/library/technote/java/codestyle.html

Of course, PrettyPrinter aims to solve some of these problems by allowing us to code with brackets/spacing as we see appropriate, and then view the source in any manner we want via PrettyPrinter at a later time. Just some thoughts...

--MasonZhwiti

The extended JTB Pretty-Printer - see the bottom of page http://www.cs.purdue.edu/homes/taokr/jtb/examples.html - automatically wraps lines longer than 80 characters nicely (taking operator priority into account). It is written using the visitor design pattern and the source code is freely available.

-BrunoDaniel

I have already written most of the perl version of the JOS PrettyPrinter, after evaluating both the JTB pretty printer and another similar PrettyPrinter someone else had mentioned a few months ago.

The problems with those versions are that they (1) take up way too much RAM, especially when dealing with large source files, and (2) are hard to maintain because of the sheer volume of visit() methods. Someone would have to study the Visitor class for some time before being able to understand what it does, let alone figure out to modify it. Even though this Visitor class may be a real "OO" way of doing things, it seems to have gone too far in this case. As Larry Wall might say, "To be sure, some folks hae gone to the opposite extreme of designing ever-growing mounds of higher-level abstractions when they should have used cut-and-paste. (This is a form of False Hubris.)"

Not that I think cut-and-paste would have helped the JTB pretty printer, I just think over-abstraction can hurt more than help. Anyway, I think it's safe to say that someone who knows Perl would be able to figure out how my program works, sufficiently enough.

On top of that, I tested it on a 20KB file, and it only took about a second to format (including HTML format). An example is on the PrettyPrinter page. I had already planned on adding wordwrap as one option, but it is not in the program yet.

--MasonZhwiti

The large memory usage of our JTB pretty-printer is mainly due to the algorithm in the current version of JavaCC. The JavaCC team has promised to fix that. I have suggested a change of JTB which reduces the memory expense of the JTB part somewhat (see the www site above). 20k files are formatted by the pretty-printer in less than a second on my machine - and it's completely written in Java.

I can't agree on your judgement of the visitor design pattern - it has many advantages over traditional ways to design a project. In this case it allows to use the same parser for completely different tasks. I think this pays very much. Consider a change of the Java grammar in a new version (e.g. the introduction of inner classes in Java 1.1). If you have used Cut and Paste, then you will have to hack the changes into all your projects.

There are tasks similar to pretty-printing which could be done:

Code transformations, e.g. automatically inserting get- and set- methods, inserting "fall through"-comments in switch statements, finding dangerous code and displaying warnings, making classes beans-compliant automatically, transforming an applet into an application...
Online pretty-printing and tinting of source code in an editor
Generation of a html-file containing a colorized version of the source code, all types being clickable links.

I'm currently working on some of these and I'm going to publish them on JTB's examples page as soon as possible.

Concerning Perl, I found a class library for using Perl's extended regular expressions in Java:

http://www.oroinc.com/products/PerlTools.html and http://www.oroinc.com/products/OROMatcher.html

-BrunoDaniel

Re: Visitor design pattern. I wasn't commenting on that design pattern, only on the this particular use of it. IMO it's hard to maintain a program with dozens of "visit()" methods in it, because the pattern loses clarity.

Re: changes in the Java language. That is a possibility, but I don't see too much changing in the syntax of the Java language past 1.1 and 1.2. I still feel it's easier in this case to tweak a regex than to consult dozens of visit() methods throughout the program. I don't see how it pays off here.

You're welcome to work on a version of PrettyPrinter that uses JTB and all the other stuff. I started one, and it was painful to say the least. I feel this version of PrettyPrinter, with a few additions and bug fixes, can get the job done in the beginning. The job being fixing everyone's source code to look similar without actually changing what the programmer wrote.

I am familiar with OroMatcher, but it is not GNU'd software and the source code is not available. Therefore I do not feel we can utilize it when writing JOS-related programs like this.

People are more than welcome to take over the JOS PrettyPrinter; I just started it because no one else had and we were starting to write code. If your JTB version is able to be freely released under the same terms as JOS itself (whatever those might be), then by all means take it over.

--MasonZhwiti

Tom, I didn't want to push you away. What about some friendly competition? (Hehe :)) We seem to have found two different approaches to solve the same problem. Why not presenting both of them to the users? The source code I write here is completely free, and JavaCC and Kevin Tao's JavaTreeBuilder seem to be free as well.

-BrunoDaniel

I think it would be a waste of someone's time if we were to both work on different approaches through to the end when only one will be used. When I first decided to get something going on PP I asked everyone there thoughts on the jos-apps list. Everyone clearly favored the approach you're taking, using Java and a real source code parser. I thought it best as well.

Then I started working on it, first with JavaCC and JJTree, then with JTB. Both methods seemed very un-intuitive, and the first time I ever felt like I was "hacking" with Java. I mean, Visitor.java has EIGHTY-NINE visit methods last time I counted. 89! Granted, most of them wouldn't be used in a good pretty printer, but they still must all be understood by the person that is maintaining the code.

The other part that concerned me was the amount of memory used, which you say will be fixed soon. So if you like working on that version of PrettyPrinter, and you feel it will be fairly simple to maintain and understand the code, then by all means take over the project. Like I said, PrettyPrinter was not a project I really wanted to work on, just one I thought needed to be done first. I would be much happier working on other parts of JOS... like FileFinder, Zip, JosMail, etc.

It's up to you. If you're familiar with Perl, I could send you the code I have so far on that just for fun.

--MasonZhwiti

I'm going to offer a version without Visitors, using only JavaCC.

-BrunoDaniel

Content of these pages are owned and copyrighted by the poster.
Hosted by: