Re: [jira] Commented: (MAHOUT-302) Change tests to use temp directories instead of output, testdata

[Sean Owen <sr...@gmail.com>]

I actually didn't intend to introduce variables used only once. I
could have made an error but usually it was because some expression
needed to be a Path, and was used at least twice. Sometimes I might
have done it for parallel style consistency across several methods. So
at least we agree there.

The formatting difference might be because of settings in my IDE
(IntelliJ) above and beyond what the standard here is, and I suspect
it's the bit that indents method arguments:

public void veryLongName(String foo
                         String bar,
                         String baz) throws IOException

(Not sure that will come through)

I only turned it loose on sections I was editing, where the arg list
was running over even the 120th column. In the religious wars over
right margin, even the extremists (me) don't go past the 120th column!


Yeah in the end this standardizes things a little bit. Could have gone
farther even but I didn't want to change too too much. I think it is
in fact handy to just request a temp directory to work with and never
have to bother checking for existence, creating it, marking for
deletion on error, deleting in tearDown(), etc.

And of course it ought to mean you can run any test in parallel with
any other test.
And of course we'd love to pop on that parallel flag to run this stuff
in parallel!



On Wed, May 5, 2010 at 4:57 AM, Jeff Eastman <jd...@windwardsolutions.com> wrote:
> +1. I read over most of the patch and see three distinct patterns:
>
> - replacing ad-hoc string arguments that name file paths with Path objects
> - replacing ad-hoc temp file allocation, deallocation with a uniform
> mechanism
> - whitespace formatting differences between your and my formatters
>
> Kudos for doing this and do you have an Eclipse formatter that handles
> method argument indenting better than mine (std Lucene AFAICT)?
> Jeff
>
> PS: I share Ted's grumpus but, mea culpa, sometimes I introduce them for
> debugging and don't inline them when I'm done. I do like them in other
> situations where they make the code clearer in complicated argument lists as
> in x.foo(y.bar().baz(), z.yak().fee().fie().foe()), but probably Ted likes
> them in those situations too.
>