The parser can cope with omitted whitespaces or having
some at any position. The way it is in the examples keeps
things readable.
Formatting is a very subjective issue. So you can do it
as you like. In a project with several authors, it is
sensible to agree on a formatting pattern.
Anyhow, what is the difference between a flow control
construct and a macro-call?
#foreach( $foo in $list )...#end
#myMacro( $bar )
In the past, in typical programming languages the brackets
on the call where glued to the name, whereas for flow-control
statements the brackets where separated from it and often
glued to the bracket contents. I see no reason for this
differentiation and observed vast readability gain doing
consistent formatting for all:
// this is dummy code
public boolean putFoo( String foo ) throws Exception
{
if( foo == null )
throw new UnsuportedArgumentException( "Argument may not be null" );
synchronized( this )
{
try
{
// do something intelligent here
}
catch( Exception ex )
{
throw new WrappedException( "Having problems...", ex );
}
}
return( ! foo.equals("") )
}
Just my 2c!
:) Christoph
Steven Shaw wrote:
> Hi, I have noticed that the Velocity examples in the user guide mostly
> put a space after a "(" and before a ")".
>
> #set( $size = "Big" )
>
> Does this help the VTL parser?
>
> Are there any downsides to using:
>
> #set ($size = "Big")
>
> #macro (foo $color)
> <tr bgcolor=$color><td>Hi</td></tr>
> <tr bgcolor=$color><td>There</td></tr>
> #end
>
> #if ($foo < 10)
> <strong>Go North</strong>
> #elseif ($foo == 10)
> <strong>Go East</strong>
> #elseif ($bar == 6)
> <strong>Go South</strong>
> #else
> <strong>Go West</strong>
> #end
>
> Cheers,
> Steve.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
