At 08:33 AM 9/16/2011 -0400, Ian Walls wrote:
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?
My two cents -- as I had noticed this, but hadn't bothered to look into it
as "if it ain't broke, don't fix it". However, I do have a question: is
there any case where a () *must* be used within a [% IF .* %]
construct? If not, then surely a one time grep -E, or perl -i could revert
matters to documented standards?
If something is not in the Koha Coding Style Guidelines wiki, then surely
we should be able to rely on the standards set by the original coders?
Ian, I really do not mean to say you're wrong, just that I think that Colin
is on a good track. After nearly a year dealing with Koha, learning a lot,
having some fun, and supplying a working system to our staff, volunteers
and members/visitors, the one "negative" factor about Koha that stands out
to me (personal opinion only) is the untidiness rather than complexity of
the coding, all leading to a general sluggishness of the system and an
increase in setup, update, modification and maintenance time.
As to your last question, QA is an absolute to ensure proper functionality
(security, etc) and intrinsically should not worry about *style*; however,
when QA is a team responsibility I have always found that lack of clarity,
including normalized practices, is counterproductive.
Best - Paul
tired old sys-admin
Cheers,
-Ian
On Fri, Sep 16, 2011 at 8:13 AM, Colin Campbell
<[email protected]> 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
--
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 845 557 5634Â (phone)
+44 (0) 7759 633626 Â (mobile)
[email protected]
skype: colin_campbell2
http://www.ptfs-europe.com
_______________________________________________
Koha-devel mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
--
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
[email protected]
Twitter: @sekjal
_______________________________________________
Koha-devel mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
_______________________________________________
Koha-devel mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
