[Koha-devel] tt style point

[LAURENT Henri-Damien]

Hi
I agree with both of you.
kohaisms are not really interesting.
And we need to try and strengthen the Coding Style GuideLines.
But then.
Who, How, When ?
Who ? should it be up to contributors or to QA manager to ensure that
coding style GuideLines are abided.
Coding Style guidelines could also state a kind of hierarchy in
folders/templates design, pod commenting. Posting some hooks and/or some
vimrc (for indentation) may help. We could improve one another way to
test and develop.

I think both should have some responsibility.
How ?
For already sent patches, new guidelines should be considered as not
appliable and it could be up to the QA queue to update the patch
and send a followup
For new patches, as soon as it is publicised in the wiki, it could be up
to the developer to comply with the guidelines.
The problem is that when the developer donot have time enough to update
the patch and the patch either fixes a bug  OR add a much desired
feature. Then anyone willing to have that patch could send a sign off
and a followup and ask for sign-off.
my 2 cts.
-- 
Henri-Damien LAURENT

Le 16/09/2011 14:33, Ian Walls a écrit :
> Colin,
> 
> 
> I made the decision to require parentheses around the variables for the
> sake of consistency.  All the other template in Koha do it that way,
> right or not.  I'm certainly open to it dropping the parentheses; they
> don't seem to follow standard practice, and while I'm sure no
> complications are introduced by them, it does add extra keystrokes and
> one more "little Koha nuance" to any patch submitted.
> 
> We have not revisited the Coding Style Guidelines for Koha since
> switching to Template Toolkit, and I think this should certainly be one
> of the issues we address when we do.  Until then, I recommend we
> maintain a consistent style in this, even if we're eventually going to
> drop it.
> 
> What does the rest of the community think?  Is it worth being picky
> about such a thing until we can decide for sure one way or the other? 
> Or, more pragmatically, should such a thing impede QA?
> 
> Cheers,
> 
> 
> -Ian
> 
> On Fri, Sep 16, 2011 at 8:13 AM, Colin Campbell
> <colin.campbell at ptfs-europe.com <mailto:colin.campbell at ptfs-europe.com>>
> wrote:
> 
>     Hi
>      I noticed that in QA someone is changing tt constructs from
>     [% IF variable %]
>     to
>     [% IF (variable) %]
>     as style issues
> 
>     I think this is very bad style for the following reasons:
>     You'll not see it in any of the documentation for tt either the perldoc,
>     on the tt site or in the badger book. (and I've never seen it on any tt
>     using project).
>     It adds nothing (we hope) syntactically.
>     My initial response is that as we are not using normal tt syntax,
>     something "clever" or magic is going on here rather than a usual [%
>     IF %]
>     It detracts from readability. (ok slightly subjective but the
>     environment already makes full use of the top row of the keyboard.)
>     Whats its relation with the legitimate use of brackets e.g. to call
>     vmethods in regexps [% IF variable1( variable2 ) %]
>     The authors didn't require brackets around more complex boolean
>     expressions [% IF variable == 0 %] why bring em back in for simple
>     variables.
>     Could it have unforeseen side effects (don't know but I don't want to
>     spend time researching it)
>     It confuses the reader of the code and the writer of subsequent code -
>     'should I use () no? when? why?
>     It strikes me as weird (!!)
> 
>     In short I'm arguing for clarity...
> 
>     I realise that Chris bracketed things in the great template conversion
>     but I think that was defensive programming when he couldn't rely on
>     variable always being one. And we shouldn't be encouraging or enforcing
>     others to use a peculiar idiolect rather than standard practice.
> 
>     Colin
> 
> 
> -- 
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com <mailto:ian.walls at bywatersolutions.com>
> Twitter: @sekjal
> 
>