Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/bindingBindin g.java JXPathBindingBase.java JXPathBindingBuilderBase.java AggregateJXPathBinding.javaJXPathBindingManager.java

[Antonio Gallardo <ag...@agssa.net>]

Vadim Gritsenko dijo:
> I think you are "overformatting" a bit - note changes in license and
> broken CVS $Id$

Thanks for reviewing. It is done on CVS.

> And please keep function arguments aligned after '('.

I am aware of this, what I am trying to do is a "trade off" between showed
code in a screen vrs. formatting of the sources. I think it is good to see
a method in just 1 screen (in eclipse we have cca. 32 lines per screen -
long time ago it was just 25 lines per screen - text consoles). Also there
is also a requirement of 80 columns per line. I try to stick to 80 cols
per line and also try to see a method in just one screen. I had a teacher
in the university that endless repeated us:

"If a function cannot be seen in just one screen, then the function is
doing too much work. Review the function and try to break it in smaller
pieces."

Of course there are some exceptions to the above rule, but are rather
rare. (Anyway, it is OT) .... I know it is old wisdom and not sure if is
still valid. It is a good idea. ie: For code reviewers it allow them to
see all the code at once.

WDYT?

Best Regards,

Antonio Gallardo

Re: Change from 80 cpl to 100 cpl standard

[Vadim Gritsenko <va...@reverycodes.com>]

Antonio Gallardo wrote:

>Vadim Gritsenko dijo:
>  
>
>>I, for myself, moved to somewhere around 100 characters per line. With
>>long Java identifiers it's not much you can fit in 80 chars ;-)
>>    
>>
>
>Yep. I agree with you. The 80 cpl (cols per line) is an old "standard" and
>we can change it if everybody agree on the Cocoon community. Need we vote
>for this? I am +1 for change to "100 cpl".
>
>The 80 cols per line was setted also to match printed version of code. But
>I am not sure if still somebody is printing code for storage. I use CD's
>to save the trees.
>
>WDYT?
>  
>

I think "use your best judgement" and I also think "don't use automatic 
code formatting tools, but rather format bad offenders (like > 120 char 
lines) only in the pieces of code you are working on" :-)

Vadim

Change from 80 cpl to 100 cpl standard (was: Re: cvs commit:...)

[Antonio Gallardo <ag...@agssa.net>]

Vadim Gritsenko dijo:
> I, for myself, moved to somewhere around 100 characters per line. With
> long Java identifiers it's not much you can fit in 80 chars ;-)

Yep. I agree with you. The 80 cpl (cols per line) is an old "standard" and
we can change it if everybody agree on the Cocoon community. Need we vote
for this? I am +1 for change to "100 cpl".

The 80 cols per line was setted also to match printed version of code. But
I am not sure if still somebody is printing code for storage. I use CD's
to save the trees.

WDYT?

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/bindingBindin g.java JXPathBindingBase.java JXPathBindingBuilderBase.java AggregateJXPathBinding.javaJXPathBindingManager.java

[Vadim Gritsenko <va...@reverycodes.com>]

Antonio Gallardo wrote:

>Vadim Gritsenko dijo:
>  
>
>>I think you are "overformatting" a bit - note changes in license and
>>broken CVS $Id$
>>    
>>
>
>Thanks for reviewing. It is done on CVS.
>  
>

Thanks :-)


>>And please keep function arguments aligned after '('.
>>    
>>
>
>I am aware of this, what I am trying to do is a "trade off" between showed
>code in a screen vrs. formatting of the sources. I think it is good to see
>a method in just 1 screen (in eclipse we have cca. 32 lines per screen -
>long time ago it was just 25 lines per screen - text consoles). Also there
>is also a requirement of 80 columns per line. I try to stick to 80 cols
>per line and also try to see a method in just one screen.
>

I, for myself, moved to somewhere around 100 characters per line. With 
long Java identifiers it's not much you can fit in 80 chars ;-)


>I had a teacher
>in the university that endless repeated us:
>
>"If a function cannot be seen in just one screen, then the function is
>doing too much work. Review the function and try to break it in smaller
>pieces."
>
>Of course there are some exceptions to the above rule, but are rather
>rare. (Anyway, it is OT) .... I know it is old wisdom and not sure if is
>still valid.
>

I'd say it is valid, with adjustments on size.

Vadim