15 Jul
2009
15 Jul
'09
3:01 p.m.
On Tue, Jul 14, 2009 at 09:13, Vincent Massol<vincent(a)massol.net> wrote:
On Jul 14, 2009, at 8:11 AM, Marius Dumitru Florea wrote:
Can you store the long string in a separate variable (maybe a
StringBuffer if it's really long)?
Marius, I see where you want to go but this will never work. You can't
modify code so that automatic formatting will always be perfect. If we
want to automate formatting (like with a SVN hook to automatically
apply code style - in a first commit for ex) then we'll have to accept
suboptimal result. The balance of course is vs wrongly formatted code
which is probably more the norm in our code in general.
I'm just whinning because I'm very strict with my code style and I
directly format it in a certain way that I find the best and the IDE
formatting removes my carefully crafted styles... ;)
I usually take care of respecting format in unit tests, i added last
minutes unit tests and forgot it.
For the "runtime code" it's usually more important for me to be sure
the code is always the same for everyone than to have lots of custom
style everywhere. Using Eclipse formater make a lots quicker and
easier to respect the checkstyle and there is not that much use cases
where it's an issue.
Vincent Massol wrote:
Why don't you use a StringBuffer?
It's more clear this way (and btw performance wise it's better - see
my other mail in response to you).
[snip]
Hi Thomas,
On Jul 13, 2009, at 3:20 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-07-13 15:20:03 +0200 (Mon, 13 Jul 2009)
> New Revision: 21910
[snip]
public
void testIncludeMacroWithNewContext() throws Exception
{
- String expected = "beginDocument\n"
- + "beginMacroMarkerStandalone [velocity] [] [$myvar]\n"
- + "beginParagraph\n"
- + "onWord [hello]\n"
- + "endParagraph\n"
- + "endMacroMarkerStandalone [velocity] [] [$myvar]\n"
- + "endDocument";
+ String expected =
+ "beginDocument\n" + "beginMacroMarkerStandalone
[velocity] [] [$myvar]\n" + "beginParagraph\n"
+ + "onWord [hello]\n" + "endParagraph\n" +
"endMacroMarkerStandalone [velocity] [] [$myvar]\n"
+ + "endDocument";
I much prefer my version. Can you please rollback? Again an example
why applying code style automatically sucks :) IncludeMacro macro = (IncludeMacro)
getComponentManager().lookup(Macro.class, "include");
mockDocumentAccessBridge
.expects
(once()).method("isDocumentViewable").will(returnValue(true));
@@ -119,7 +120,7 @@
assertBlocks(expected, blocks);
}
-
+
public void testIncludeMacroWithNoDocumentSpecified() throws
Exception
{
IncludeMacro macro = (IncludeMacro)
getComponentManager().lookup(Macro.class, "include");
@@ -129,8 +130,8 @@
macro.execute(parameters, null, new
MacroTransformationContext());
fail("An exception should have been thrown");
} catch (MacroExecutionException expected) {
- assertEquals("You must specify a 'document' parameter
pointing to the document to include.",
- expected.getMessage());
+ assertEquals("You must specify a 'document' parameter
pointing to the document to include.", expected
+ .getMessage());
again a brilliant example why it sucks... :(
If we could improve the IDE styles it could be ok. But I don't think
Eclipse for ex support things like:
- put braces on next line for if/for/etc only if the line is longer
than 120 chars. We could also decide to remove this rule we had voted
and (which I personally like - my preference has always been braces on
next line everywhere for increased readability)
I would prefer choosing having the braces on next line (note i was not
here for this vote) than saing it's impossible to use Eclipse
formatter.
- don't split on "." (as in the example
above)
I quickly looked and Eclipse formatter support this very well when you
configure it.
- don't split for javadoc @see (to be verified
this is invalid - I
seem to recall it is)
Javadoc is splited only when it's longer than 120 characters so there
is no issue
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne