> NP. The only style that really is an issue for me is liberal sprinkling > of Javadoc.
Yeah, sure, no arguments. I've been excited to get some stuff up and running, so obviously took lots of short cuts .. my first submission for the parser looked more like pascal code! Todays patch will be cleanups, javadocs and tests, and maybe a working formula viewer. Regards - Avik PS. i wanted to know, should we be writing biff7 or biff8? Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > Avik Sengupta wrote: > > >I have attached my latest patches to bugzilla that adds the ability to do > >floats. All existing tests pass .. i will write up new tests for floats soon > .. > >promise :) > > > I found writing tests first was kind of fun and useful. Make a failing > test and watch it succeed as you make more POI. Of course I coudln't > do this everywhere. Plus Glen will love you. (that may be a downside ;-) > ) > > > > >I have added a new NumberPtg.java, modelled on the existing records and Ptg. > > >Tell me if its messed up somehow. (My knowledge of HSSF internals can only > go > >up at the moment :) > > > Will look at it in about 5 hours or so. I'll patch and test. I'm > really excited about the code you've been submitting. > > > > > > >I have also changed one line in the areareference code in FormulaParser to > go > >better with the style of the rest of the class. hope you dont mind. > > > NP. The only style that really is an issue for me is liberal sprinkling > of Javadoc. I LOVE IT! We'll need to bring this stuff up to snuff > soon. See: > > http://jakarta.apache.org/poi/resolutions/res001.html for details. We > also need to start making sure that unit tests are heavily utilized. > Believe me, if you think its pedantic now....you won't later. Every > problem I've had trouble tracking down was in an un-unit tested class. > For instance adding formulas put in a variable sized cell value record. > Well that broke things in HSSF. Guess what....no unit tests for that > section of code....doh! So they are absolutely essential for this > project. As new things develop old assumptions prove false and unit > tests are the best way to know immediately! > > > > >Andy, a couple of questions for you... > > > >1. Can we remove the toFormulaString(Ptg[] operands) method, and keep only > the > >String[] ones? To do a recursive evalutation of an RPN ptg array, you need > the > >String one. i cant find an use case for the ptg[] method. > > > Yes. > > > > >2. Can we remove the getStringLength method? i dont understand where it is > > >used. > > > If you're not using it lets remove it. I did my best to trim the tree > but may have missed a couple spots. > > > > >Thanks > >- > >Avik > > > >PS. having added the cell ref and area ref code to the parser, i hope you > agree > >that its simple :) > > > Yes. There are a few things I may still want to move off into the PTG > classes, but I've abandoned my earlier approach in favor of yours. (I > think you've started doing this anyhow from a quick glimpse of your > patch). Basically, the way I work is, "find the best approach" and I > think you've done it. So I'm excited to be working with you on this. > Keep it up. > > -Andy > > >
