On 3 Jul 2013 14:06, "Steve Ebersole" wrote:
>
> I vote for having spaces in the method/constructor usages.
I'm not seeing the need for spaces when invoking a constructor, but I am ok
with it.
>
> Like Gunnar (iirc) said earlier, I find having the usages be consistent
and
> different from the de
I vote for having spaces in the method/constructor usages.
Like Gunnar (iirc) said earlier, I find having the usages be consistent and
different from the declarations to be a simple but effective visual clue as
I look through the source.
That's just my feelings though..
On Jul 3, 2013 7:52 AM, "
On 3 Jan 2013, at 2:52 PM, Steve Ebersole wrote:
> Well you assume it is consistent, which I agree is the important point it
> determining whether to make this a rule. So let's examine that...
>
> Would you also agree that this is better:
>
> private void doIt (String it) { ... }
>
> than:
>
Well the trouble is that the "don't double up parens without spaces" rule
does not exist. I guess you and Davide could tackle that with y'alls
regex-fu though :)
Tbh for me I think we should be looking at long parameter lists, both in
terms if validating their use and how they are expressed. We
Well you assume it is consistent, which I agree is the important point it
determining whether to make this a rule. So let's examine that...
Would you also agree that this is better:
private void doIt (String it) { ... }
than:
private void doIt ( String it ) { ... }
?
Which ruleset should cat
2013/7/3 Steve Ebersole
> The "original" rule was that parens should always be separated by spaces.
> E.g.:
>
> if (isTrue ()) { ... }
>
> Is clearly fugly.
>
> if ( isTrue () ) { ... }
>
> To me is clearly more readable.
>
> Method/constructor declarations do not use spaces inside parens simply
On 3 Jan 2013, at 2:36 PM, Steve Ebersole wrote:
> The "original" rule was that parens should always be separated by spaces.
> E.g.:
>
> if (isTrue ()) { ... }
>
> Is clearly fugly.
>
> if ( isTrue () ) { ... }
>
> To me is clearly more readable.
Sure, I agree on you on that
> Method/con
The "original" rule was that parens should always be separated by spaces.
E.g.:
if (isTrue ()) { ... }
Is clearly fugly.
if ( isTrue () ) { ... }
To me is clearly more readable.
Method/constructor declarations do not use spaces inside parens simply
because the arguments list cannot contain par
I'm voting for having white spaces in catch as well as constructor
invocations, the reason being to ensure a consistent style with method
invocations, if, while etc. I don't see an advantage in having white space
in some of these constructs but not in others.
2013/7/3 Steve Ebersole
> There is
There is a mix in ORM as well. My vote is for no spaces inside the parens
for catch statements. I do like the spaces for if, for, while, etc though.
On Jul 3, 2013 5:29 AM, "Hardy Ferentschik" wrote:
> +1 for 'catch ( IllegalArgumentException e )' - using white spaces
>
> On 3 Jan 2013, at 11:
+1 for 'catch ( IllegalArgumentException e )' - using white spaces
On 3 Jan 2013, at 11:07 AM, Sanne Grinovero wrote:
> Looking at the following patch:
>
>
> }
> -catch (IllegalArgumentException e) {
> +catch ( IllegalArgumentException e ) {
>
> would you consider it an improvement i
11 matches
Mail list logo
