+1 for (3)
Michael
On 10/17/09 3:55 AM, Uwe Schindler wrote:
Just because I came along a lot of new Generics declarations:
How should we handle generics parameters in the source code? There are more
possibilities:
1. Map
2. Map
3. Map
Sun's Java code in src.jar of their JDK always uses (3)[
+1 for option 3
Mike
On Sat, Oct 17, 2009 at 6:55 AM, Uwe Schindler wrote:
> Just because I came along a lot of new Generics declarations:
> How should we handle generics parameters in the source code? There are more
> possibilities:
>
> 1. Map
> 2. Map
> 3. Map
>
> Sun's Java code in src.jar o
Uwe Schindler wrote:
> Just because I came along a lot of new Generics declarations:
> How should we handle generics parameters in the source code? There are more
> possibilities:
>
> 1. Map
> 2. Map
> 3. Map
>
> Sun's Java code in src.jar of their JDK always uses (3)[only in some special
> cases,
Always used 1.
That's also the default for many autoformatters, which probably
explains why people use it.
On Sat, Oct 17, 2009 at 14:55, Uwe Schindler wrote:
> Just because I came along a lot of new Generics declarations:
> How should we handle generics parameters in the source code? There are m
Just because I came along a lot of new Generics declarations:
How should we handle generics parameters in the source code? There are more
possibilities:
1. Map
2. Map
3. Map
Sun's Java code in src.jar of their JDK always uses (3)[only in some special
cases, when it gets complicated, like when ?
[
https://issues.apache.org/jira/browse/LUCENE-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1610.
Resolution: Fixed
Thanks Steve!
> Preserve whitespace in sections in
p;lt;code> ) and is converted to (instead of to
</code> )
> Preserve whitespace in sections in the Changes.html generated from
> CHANGES.
Preserve whitespace in sections in the Changes.html generated from
CHANGES.txt by changes2html.pl
Key: LUCENE-1610
URL: https://issues.apache.org/jira
[
https://issues.apache.org/jira/browse/LUCENE-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1122:
Priority: Minor (was: Major)
> queryparser whitespace escaping and documentat
p of TERM_START_CHAR + TERM_CHAR*, both of which can
contain an ESCAPED_CHAR, which is an escape, '\', followed by anything. So
backslash space matches ESCAPED_CHAR, and the space is eaten as part of the
term rather than being used as a whitespace break.
We could change it, or it sounds like its fi
lusively of terms in the default
field) would no longer be supported. In this case, the Javadocs should be
changed to be very explicit about the supported use case(s).
> queryparser whitespace escaping and documentation?
> --
>
&
queryparser whitespace escaping and documentation?
--
Key: LUCENE-1122
URL: https://issues.apache.org/jira/browse/LUCENE-1122
Project: Lucene - Java
Issue Type: Improvement
Yonik Seeley wrote:
The java coding standards do say
"Spaces after keywords but no spaces either before or after
parentheses in method calls"
"if (a)" and "foo(a)"
Lucene's formatting guidelines are stated at:
http://wiki.apache.org/lucene-java/HowToContribute
In short, they say: Sun's conve
Just my 2 cents.
I think it is good to use tooling to establish a whitespace standard
for new files. For example, Eclipse has extensive formating and one
of the declared styles is Sun's. Checkstyle is also good at creating
a report of deviations from a defined standard. And it c
: The java coding standards do say
: "Spaces after keywords but no spaces either before or after
: parentheses in method calls"
:
: "if (a)" and "foo(a)"
that's fairly readable in general, but i have found that when dealing with
complex conditionals, a little extra white space can make some thing
On 3/25/07, Michael McCandless (JIRA) <[EMAIL PROTECTED]> wrote:
My first comment, which I fear will be the most controversial feedback
here :), is a whitespace style question: I'm not really a fan of
"cancerous whitespace" where every ( [ etc has its own whitespace
ar
16 matches
Mail list logo