[Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Jonny Bradley-4
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>> • Document
>>>>> • Rename to something like "setRawHTML"
>>>>> • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier.com
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> _______________________________________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Jean-Marc Libs
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier.com
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> _______________________________________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

luciash d' being

+1 to stay with tabs!

luci


On 16.1.2017 21:00, Jean-Marc Libs wrote:
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier.com
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> _______________________________________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Torsten Fabricius-4
Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs

+1 for tabs!

On 16.01.2017 21:12, luciash wrote:

+1 to stay with tabs!

luci


On 16.1.2017 21:00, Jean-Marc Libs wrote:
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier.com
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> _______________________________________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

gezzzan
an evergreen topic :)

+1 for spaces!  only because I also code in python and I am lazy and would be nice to have it the same way in tiki

but I know it will not change, and I can live with tabs..

and yes, this can lead to a fierce discussion: https://www.youtube.com/watch?v=SsoOG6ZeyUI

:)


From: Torsten <[hidden email]>
To: Tiki developers <[hidden email]>
Sent: Monday, January 16, 2017 9:19 PM
Subject: Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs

+1 for tabs!

On 16.01.2017 21:12, luciash wrote:
+1 to stay with tabs!
luci

On 16.1.2017 21:00, Jean-Marc Libs wrote:
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email][hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier. com
>>>>>
>>>>>
>>>>> ------------------------------ ------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------ ------------------------------ ------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> ______________________________ _________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------ ------------------------------ ------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______ ______________________________ __________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------ ------------------------------ ------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ______________________________ _________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------ ------------------------------ ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ______________________________ _________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs


------------------------------ ------------------------------ ------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
______________________________ _________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/ lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Torsten Fabricius-4
This video is hilarious. Must see. Thx Gezza for sharing!

T.

On 16.01.2017 21:39, gezzzan wrote:
an evergreen topic :)

+1 for spaces!  only because I also code in python and I am lazy and would be nice to have it the same way in tiki

but I know it will not change, and I can live with tabs..

and yes, this can lead to a fierce discussion: https://www.youtube.com/watch?v=SsoOG6ZeyUI

:)


From: Torsten [hidden email]
To: Tiki developers [hidden email]
Sent: Monday, January 16, 2017 9:19 PM
Subject: Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs

+1 for tabs!

On 16.01.2017 21:12, luciash wrote:
+1 to stay with tabs!
luci

On 16.1.2017 21:00, Jean-Marc Libs wrote:
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier. com
>>>>>
>>>>>
>>>>> ------------------------------ ------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------ ------------------------------ ------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> ______________________________ _________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------ ------------------------------ ------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______ ______________________________ __________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------ ------------------------------ ------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ______________________________ _________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------ ------------------------------ ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ______________________________ _________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/ lists/listinfo/tikiwiki-cvs


------------------------------ ------------------------------ ------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
______________________________ _________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/ lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Brendan Ferguson
In reply to this post by Torsten Fabricius-4
Good topic on the tabs-spaces. I am +1 for picking one and sticking with it. It really does not matter to me. I thought at one point that tiki was using spaces, but have seen a real mix in the code.

Might I suggest that we make a decision, stick with it and then have everyone change their phpStorm settings? That way people want to wear out their space bar, their welcome to! I think we are all pretty much using phpStorm anyhow, and most editors have similar options. One can even Edit -> Convert Indents. Assuming some hoser didnt use 3 spaces instead of 4 (ya, I know you have seen it too)

I would however suggest tabs.... why? We use css, js and tpl files where the spacing does impact the file size of user downloads. We currently dont have a HTML minimization process, so all that whitespace gets passed down to the client. If we had a HTML minifyer installed on tiki, I would say.... no opinion, so long as were all trying to do the same thing. (ya i know whitespace is compressed really well, but some sites dont use it, and its still not quite as small)

So I guess my strongest opinion is to post the steps to change the settings in phpStorm, make it part of the setup process that is posted..... If one of the one we decide against starts appearing in the code, we can ask the person to change their settings.

BTW. My personal preference in coding is 2 spaces ;) I find 4 is a little excessive; how are you suppose to read those lines of code that are nested in 12+ control statements? lol. PEAR wrecked all that when it came out. I was so shocked and PISSED when I saw 4 spaces..... I had always used 2 or 3, but 4? If the world evolved around me, all tabs would be set at 2 spaces!

Brendan

On Tue, Jan 17, 2017 at 5:19 AM, Torsten <[hidden email]> wrote:
Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs

+1 for tabs!


On 16.01.2017 21:12, luciash wrote:

+1 to stay with tabs!

luci


On 16.1.2017 21:00, Jean-Marc Libs wrote:
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email][hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier.com
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> _______________________________________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Tiki-devel] Indentation character (Re: Tiki coding conventions)

Filipus Klutiero
In reply to this post by Torsten Fabricius-4
I am not sure what Jonny means by spaces never go wrong, but I prefer tabs as well.

On 2017-01-16 15:19, Torsten wrote:
Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs

+1 for tabs!

On 16.01.2017 21:12, luciash wrote:

+1 to stay with tabs!

luci


On 16.1.2017 21:00, Jean-Marc Libs wrote:
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier.com
>>>>>
>>>>>

-- 
Filipus Klutiero
http://www.philippecloutier.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions

Filipus Klutiero
In reply to this post by Jonny Bradley-4
I am not that attached to camelCase, but I do care about keeping our conventions accurate and concise.
  1. Conventions should be documented.
  2. I am reluctant to complexify our rules. Therefore, instead of saying a new function should be named according to its file's existing functions, I would find it less problematic to simply explain that large parts of Tiki do not respect our standards, and that additions to non-complying parts are not expected to comply with standards.
On 2017-01-16 14:17, Jonny Bradley wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




On 16 Jan 2017, at 18:10, Victor Emanouilov [hidden email] wrote:

I have pondered this myself - things get even more confusing for large 
libs like trackerlib or service controllers where we have a mix - large 
set of snake_case vs small set of camelCased functions. Do we have an 
agreement as to what case should the new functions be in those files?

Regards,
Victor

On 01/16/2017 04:13 PM, Jonny Bradley wrote:
+1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.

I suggest we add another exception to the Zend standards?

jb



On 16 Jan 2017, at 14:07, Brendan Ferguson [hidden email] wrote:

I hope all the other authors of the functions in that file get arrested too! ;)

Yup. I was caught as well!

Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.

Brendan


Can you send me a link? I just followed the convention of the already existing functions in the headerlib...

luci


Other than that, I find this function counter-intuitive. Please either:
	• Document
	• Rename to something like "setRawHTML"
	• Concatenate the argument to $this->rawhtml rather than overwriting


-- 
Filipus Klutiero

http://www.philippecloutier.com




-- 
Filipus Klutiero
http://www.philippecloutier.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Indentation character (Re: Tiki coding conventions)

Brendan Ferguson
In reply to this post by Filipus Klutiero

On Tue, Jan 17, 2017 at 9:39 AM, Filipus Klutiero <[hidden email]> wrote:
I am not sure what Jonny means by spaces never go wrong, but I prefer tabs as well.

If all you do is spaces, it will always look the same,

If tabs are used and you have letters or a space taking up part of a line, then it really depends on your editor tab settings. Someone who uses tabs taking up 2 spaces will see it differently than someone who has them set at 4.

The files also tend to look really broken if they are viewed in a text viewing application that does not use a monospace font, or who does not define tab spaces at that standard. Viewing the code on the web causes similar issues, cause the tab is treated as a space. If you have 4 spaces, you can use the code snipit to keep the spacing, but it still wont work quite right with the tabs.

So arguably, the most consistent approach is to use spaces all the time.

Since our editors will convert 4-spaces to tabs and vice versa, its not really a matter of what key we like hitting (although this must be setup generally, so it does impact the noobs)

Using spaces does create larger file sizes. Its larger on disk and although whitespace almost completely compressed down through gzip (or any other compression), its still a bit larger. So it effects everything slighty, but has a dramatic effect on web storage and download times with servers who dont have gzip compression enabled. (but they are all small files anyhow)

The best part is really flame warring over it. It should all be changed to tabs set at 3 spaces :0!

Brendan


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions

Brendan Ferguson
In reply to this post by Filipus Klutiero

  1. Conventions should be documented.
  2. I am reluctant to complexify our rules. Therefore, instead of saying a new function should be named according to its file's existing functions, I would find it less problematic to simply explain that large parts of Tiki do not respect our standards, and that additions to non-complying parts are not expected to comply with standards.
+1
 
On 2017-01-16 14:17, Jonny Bradley wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




On 16 Jan 2017, at 18:10, Victor Emanouilov [hidden email] wrote:

I have pondered this myself - things get even more confusing for large 
libs like trackerlib or service controllers where we have a mix - large 
set of snake_case vs small set of camelCased functions. Do we have an 
agreement as to what case should the new functions be in those files?

Regards,
Victor

On 01/16/2017 04:13 PM, Jonny Bradley wrote:
+1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.

I suggest we add another exception to the Zend standards?

jb



On 16 Jan 2017, at 14:07, Brendan Ferguson [hidden email] wrote:

I hope all the other authors of the functions in that file get arrested too! ;)

Yup. I was caught as well!

Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.

Brendan


Can you send me a link? I just followed the convention of the already existing functions in the headerlib...

luci


Other than that, I find this function counter-intuitive. Please either:
	• Document
	• Rename to something like "setRawHTML"
	• Concatenate the argument to $this->rawhtml rather than overwriting


-- 
Filipus Klutiero

http://www.philippecloutier.com




-- 
Filipus Klutiero
http://www.philippecloutier.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions

Victor Emanouilov
In reply to this post by Filipus Klutiero

Yeah, this makes sense!

Thanks,

Victor


On 01/17/2017 03:24 AM, Filipus Klutiero wrote:
I am not that attached to camelCase, but I do care about keeping our conventions accurate and concise.
  1. Conventions should be documented.
  2. I am reluctant to complexify our rules. Therefore, instead of saying a new function should be named according to its file's existing functions, I would find it less problematic to simply explain that large parts of Tiki do not respect our standards, and that additions to non-complying parts are not expected to comply with standards.
On 2017-01-16 14:17, Jonny Bradley wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




On 16 Jan 2017, at 18:10, Victor Emanouilov [hidden email] wrote:

I have pondered this myself - things get even more confusing for large 
libs like trackerlib or service controllers where we have a mix - large 
set of snake_case vs small set of camelCased functions. Do we have an 
agreement as to what case should the new functions be in those files?

Regards,
Victor

On 01/16/2017 04:13 PM, Jonny Bradley wrote:
+1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.

I suggest we add another exception to the Zend standards?

jb



On 16 Jan 2017, at 14:07, Brendan Ferguson [hidden email] wrote:

I hope all the other authors of the functions in that file get arrested too! ;)

Yup. I was caught as well!

Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.

Brendan


Can you send me a link? I just followed the convention of the already existing functions in the headerlib...

luci


Other than that, I find this function counter-intuitive. Please either:
	• Document
	• Rename to something like "setRawHTML"
	• Concatenate the argument to $this->rawhtml rather than overwriting


-- 
Filipus Klutiero

http://www.philippecloutier.com




-- 
Filipus Klutiero
http://www.philippecloutier.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Jonny Bradley-4
In reply to this post by Brendan Ferguson

Tiki has never used spaces, it's always been tabs but most IDE's default to use spaces (as does Zend) so we end up with a mix and messy broken indentation. I hear Jean-Marc's desire to have two char tabs to fit on a small screen so i guess we're stuck with them :)

There are a couple of PhpStorm settings files attached to https://dev.tiki.org/PhpStorm (one jar for current versions and an xml for old ones i think) please update or improve it if you can! :)

HTH

jonny





> On 17 Jan 2017, at 00:37, Brendan Ferguson <[hidden email]> wrote:
>
> Good topic on the tabs-spaces. I am +1 for picking one and sticking with it. It really does not matter to me. I thought at one point that tiki was using spaces, but have seen a real mix in the code.
>
> Might I suggest that we make a decision, stick with it and then have everyone change their phpStorm settings? That way people want to wear out their space bar, their welcome to! I think we are all pretty much using phpStorm anyhow, and most editors have similar options. One can even Edit -> Convert Indents. Assuming some hoser didnt use 3 spaces instead of 4 (ya, I know you have seen it too)
>
> I would however suggest tabs.... why? We use css, js and tpl files where the spacing does impact the file size of user downloads. We currently dont have a HTML minimization process, so all that whitespace gets passed down to the client. If we had a HTML minifyer installed on tiki, I would say.... no opinion, so long as were all trying to do the same thing. (ya i know whitespace is compressed really well, but some sites dont use it, and its still not quite as small)
>
> So I guess my strongest opinion is to post the steps to change the settings in phpStorm, make it part of the setup process that is posted..... If one of the one we decide against starts appearing in the code, we can ask the person to change their settings.
>
> BTW. My personal preference in coding is 2 spaces ;) I find 4 is a little excessive; how are you suppose to read those lines of code that are nested in 12+ control statements? lol. PEAR wrecked all that when it came out. I was so shocked and PISSED when I saw 4 spaces..... I had always used 2 or 3, but 4? If the world evolved around me, all tabs would be set at 2 spaces!
>
> Brendan
>
> On Tue, Jan 17, 2017 at 5:19 AM, Torsten <[hidden email]> wrote:
>> Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs
>>
>> +1 for tabs!
>>
>>
>> On 16.01.2017 21:12, luciash wrote:
>>> +1 to stay with tabs!
>>>
>>> luci
>>>
>>> On 16.1.2017 21:00, Jean-Marc Libs wrote:
>>>> I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.
>>>>
>>>> Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
>>>> My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.
>>>>
>>>> On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
>>>> Hi Victor and all (moving this from csv to dev list)
>>>>
>>>> The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)
>>>>
>>>> Certainly everything inside lib/core should be camel style i think and should stay that way.
>>>>
>>>> While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)
>>>>
>>>> Discuss! :)
>>>>
>>>> jonny
>>>>
>>>>
>>>>
>>>>
>>>> > On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>>>> >
>>>> > I have pondered this myself - things get even more confusing for large
>>>> > libs like trackerlib or service controllers where we have a mix - large
>>>> > set of snake_case vs small set of camelCased functions. Do we have an
>>>> > agreement as to what case should the new functions be in those files?
>>>> >
>>>> > Regards,
>>>> > Victor
>>>> >
>>>> > On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>>> >>
>>>> >> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>>> >>
>>>> >> I suggest we add another exception to the Zend standards?
>>>> >>
>>>> >> jb
>>>> >>
>>>> >>
>>>> >>
>>>> >>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>> >>>
>>>> >>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>> >>>
>>>> >>> Yup. I was caught as well!
>>>> >>>
>>>> >>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>> >>>
>>>> >>> Brendan
>>>> >>>
>>>> >>>
>>>> >>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>> >>>>
>>>> >>>> luci
>>>> >>>>
>>>> >>>>
>>>> >>>>> Other than that, I find this function counter-intuitive. Please either:
>>>> >>>>>   • Document
>>>> >>>>>   • Rename to something like "setRawHTML"
>>>> >>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>> Filipus Klutiero
>>>> >>>>>
>>>> >>>>> http://www.philippecloutier.com
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> ------------------------------------------------------------
>>>> >>>>> ------------------
>>>> >>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> >>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >>>>> With one year of Intel Parallel Studio XE.
>>>> >>>>> Training and support from Colfax.
>>>> >>>>> Order your platform today.
>>>> >>>>> http://sdm.link/xeonphi
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> ______________________________
>>>> >>>>> _________________
>>>> >>>>> Tikiwiki-cvs mailing list
>>>> >>>>>
>>>> >>>>> [hidden email]
>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >>>>
>>>> >>>> ------------------------------------------------------------------------------
>>>> >>>> Developer Access Program for Intel Xeon Phi Processors
>>>> >>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >>>> With one year of Intel Parallel Studio XE.
>>>> >>>> Training and support from Colfax.
>>>> >>>> Order your platform today. http://sdm.link/xeonphi
>>>> >>>> _______________________________________________
>>>> >>>> Tikiwiki-cvs mailing list
>>>> >>>> [hidden email]
>>>> >>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >>>
>>>> >>> ------------------------------------------------------------------------------
>>>> >>> Developer Access Program for Intel Xeon Phi Processors
>>>> >>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >>> With one year of Intel Parallel Studio XE.
>>>> >>> Training and support from Colfax.
>>>> >>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>>> >>> Tikiwiki-cvs mailing list
>>>> >>> [hidden email]
>>>> >>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> Developer Access Program for Intel Xeon Phi Processors
>>>> >> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >> With one year of Intel Parallel Studio XE.
>>>> >> Training and support from Colfax.
>>>> >> Order your platform today. http://sdm.link/xeonphi
>>>> >> _______________________________________________
>>>> >> Tikiwiki-cvs mailing list
>>>> >> [hidden email]
>>>> >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Check out the vibrant tech community on one of the world's most
>>>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> > _______________________________________________
>>>> > Tikiwiki-cvs mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org!
>>>> http://sdm.link/slashdot
>>>>
>>>>
>>>> ______________________________
>>>> _________________
>>>> TikiWiki-devel mailing list
>>>>
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org!
>>> http://sdm.link/slashdot
>>>
>>>
>>> ______________________________
>>> _________________
>>> TikiWiki-devel mailing list
>>>
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Brendan Ferguson
While, I guess thats that. People seem to want tabs.... I wouldn't mind changing. I was thinking of trying to do something about the crazy whitespace in our HTML files.... I think the best option is a good HTML Parser Minifyer though, so before hand spacing is while.... irrelevant in that case.

Honestly, though, as long as file is constant its dosent really bug me. I swing both ways :)

Brendan

On Tue, Jan 17, 2017 at 7:34 PM, Jonny Bradley <[hidden email]> wrote:

Tiki has never used spaces, it's always been tabs but most IDE's default to use spaces (as does Zend) so we end up with a mix and messy broken indentation. I hear Jean-Marc's desire to have two char tabs to fit on a small screen so i guess we're stuck with them :)

There are a couple of PhpStorm settings files attached to https://dev.tiki.org/PhpStorm (one jar for current versions and an xml for old ones i think) please update or improve it if you can! :)

HTH

jonny





> On 17 Jan 2017, at 00:37, Brendan Ferguson <[hidden email]> wrote:
>
> Good topic on the tabs-spaces. I am +1 for picking one and sticking with it. It really does not matter to me. I thought at one point that tiki was using spaces, but have seen a real mix in the code.
>
> Might I suggest that we make a decision, stick with it and then have everyone change their phpStorm settings? That way people want to wear out their space bar, their welcome to! I think we are all pretty much using phpStorm anyhow, and most editors have similar options. One can even Edit -> Convert Indents. Assuming some hoser didnt use 3 spaces instead of 4 (ya, I know you have seen it too)
>
> I would however suggest tabs.... why? We use css, js and tpl files where the spacing does impact the file size of user downloads. We currently dont have a HTML minimization process, so all that whitespace gets passed down to the client. If we had a HTML minifyer installed on tiki, I would say.... no opinion, so long as were all trying to do the same thing. (ya i know whitespace is compressed really well, but some sites dont use it, and its still not quite as small)
>
> So I guess my strongest opinion is to post the steps to change the settings in phpStorm, make it part of the setup process that is posted..... If one of the one we decide against starts appearing in the code, we can ask the person to change their settings.
>
> BTW. My personal preference in coding is 2 spaces ;) I find 4 is a little excessive; how are you suppose to read those lines of code that are nested in 12+ control statements? lol. PEAR wrecked all that when it came out. I was so shocked and PISSED when I saw 4 spaces..... I had always used 2 or 3, but 4? If the world evolved around me, all tabs would be set at 2 spaces!
>
> Brendan
>
> On Tue, Jan 17, 2017 at 5:19 AM, Torsten <[hidden email]> wrote:
>> Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs
>>
>> +1 for tabs!
>>
>>
>> On 16.01.2017 21:12, luciash wrote:
>>> +1 to stay with tabs!
>>>
>>> luci
>>>
>>> On 16.1.2017 21:00, Jean-Marc Libs wrote:
>>>> I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.
>>>>
>>>> Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
>>>> My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.
>>>>
>>>> On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
>>>> Hi Victor and all (moving this from csv to dev list)
>>>>
>>>> The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)
>>>>
>>>> Certainly everything inside lib/core should be camel style i think and should stay that way.
>>>>
>>>> While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)
>>>>
>>>> Discuss! :)
>>>>
>>>> jonny
>>>>
>>>>
>>>>
>>>>
>>>> > On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email]> wrote:
>>>> >
>>>> > I have pondered this myself - things get even more confusing for large
>>>> > libs like trackerlib or service controllers where we have a mix - large
>>>> > set of snake_case vs small set of camelCased functions. Do we have an
>>>> > agreement as to what case should the new functions be in those files?
>>>> >
>>>> > Regards,
>>>> > Victor
>>>> >
>>>> > On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>>> >>
>>>> >> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>>> >>
>>>> >> I suggest we add another exception to the Zend standards?
>>>> >>
>>>> >> jb
>>>> >>
>>>> >>
>>>> >>
>>>> >>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>> >>>
>>>> >>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>> >>>
>>>> >>> Yup. I was caught as well!
>>>> >>>
>>>> >>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>> >>>
>>>> >>> Brendan
>>>> >>>
>>>> >>>
>>>> >>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>> >>>>
>>>> >>>> luci
>>>> >>>>
>>>> >>>>
>>>> >>>>> Other than that, I find this function counter-intuitive. Please either:
>>>> >>>>>   • Document
>>>> >>>>>   • Rename to something like "setRawHTML"
>>>> >>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>> Filipus Klutiero
>>>> >>>>>
>>>> >>>>> http://www.philippecloutier.com
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> ------------------------------------------------------------
>>>> >>>>> ------------------
>>>> >>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> >>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >>>>> With one year of Intel Parallel Studio XE.
>>>> >>>>> Training and support from Colfax.
>>>> >>>>> Order your platform today.
>>>> >>>>> http://sdm.link/xeonphi
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> ______________________________
>>>> >>>>> _________________
>>>> >>>>> Tikiwiki-cvs mailing list
>>>> >>>>>
>>>> >>>>> [hidden email]
>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >>>>
>>>> >>>> ------------------------------------------------------------------------------
>>>> >>>> Developer Access Program for Intel Xeon Phi Processors
>>>> >>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >>>> With one year of Intel Parallel Studio XE.
>>>> >>>> Training and support from Colfax.
>>>> >>>> Order your platform today. http://sdm.link/xeonphi
>>>> >>>> _______________________________________________
>>>> >>>> Tikiwiki-cvs mailing list
>>>> >>>> [hidden email]
>>>> >>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >>>
>>>> >>> ------------------------------------------------------------------------------
>>>> >>> Developer Access Program for Intel Xeon Phi Processors
>>>> >>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >>> With one year of Intel Parallel Studio XE.
>>>> >>> Training and support from Colfax.
>>>> >>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>>> >>> Tikiwiki-cvs mailing list
>>>> >>> [hidden email]
>>>> >>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> Developer Access Program for Intel Xeon Phi Processors
>>>> >> Access to Intel Xeon Phi processor-based developer platforms.
>>>> >> With one year of Intel Parallel Studio XE.
>>>> >> Training and support from Colfax.
>>>> >> Order your platform today. http://sdm.link/xeonphi
>>>> >> _______________________________________________
>>>> >> Tikiwiki-cvs mailing list
>>>> >> [hidden email]
>>>> >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Check out the vibrant tech community on one of the world's most
>>>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> > _______________________________________________
>>>> > Tikiwiki-cvs mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org!
>>>> http://sdm.link/slashdot
>>>>
>>>>
>>>> ______________________________
>>>> _________________
>>>> TikiWiki-devel mailing list
>>>>
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org!
>>> http://sdm.link/slashdot
>>>
>>>
>>> ______________________________
>>> _________________
>>> TikiWiki-devel mailing list
>>>
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions [was Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[60884] trunk/lib]

Jean-Marc Libs
In reply to this post by Brendan Ferguson


On Tue, Jan 17, 2017 at 1:37 AM, Brendan Ferguson <[hidden email]> wrote:
Good topic on the tabs-spaces. I am +1 for picking one and sticking with it. It really does not matter to me. I thought at one point that tiki was using spaces, but have seen a real mix in the code.

It's always been tabs, even after we decided to not write our own coding standards from scratch any more and base them on Zend's:
https://dev.tiki.org/DevTips#PHP_coding_habits
 

Might I suggest that we make a decision, stick with it and then have everyone change their phpStorm settings? That way people want to wear out their space bar, their welcome to! I think we are all pretty much using phpStorm anyhow, and most editors have similar options. One can even Edit -> Convert Indents. Assuming some hoser didnt use 3 spaces instead of 4 (ya, I know you have seen it too)

Well, my attempt at setting up phpstorm failed again last week, but that's besides the point :)
 

I would however suggest tabs.... why? We use css, js and tpl files where the spacing does impact the file size of user downloads. We currently dont have a HTML minimization process, so all that whitespace gets passed down to the client. If we had a HTML minifyer installed on tiki, I would say.... no opinion, so long as were all trying to do the same thing. (ya i know whitespace is compressed really well, but some sites dont use it, and its still not quite as small)

So I guess my strongest opinion is to post the steps to change the settings in phpStorm, make it part of the setup process that is posted..... If one of the one we decide against starts appearing in the code, we can ask the person to change their settings.

BTW. My personal preference in coding is 2 spaces ;) I find 4 is a little excessive; how are you suppose to read those lines of code that are nested in 12+ control statements? lol. PEAR wrecked all that when it came out. I was so shocked and PISSED when I saw 4 spaces..... I had always used 2 or 3, but 4? If the world evolved around me, all tabs would be set at 2 spaces!

I once went through all files to make sure there were no mixes and everything used tabs (or spaces for good reasons), but this can not be done at any time as it makes merges hard. Jonny told me when was the proper opportunity window. I could do it again some day (after we have a new server).

Cheers,
J-M



Brendan

On Tue, Jan 17, 2017 at 5:19 AM, Torsten <[hidden email]> wrote:
Not being a coder, but regularly having to do with code-files, .csv, .css etc., I (strongly) opt aswell for tabs

+1 for tabs!


On 16.01.2017 21:12, luciash wrote:

+1 to stay with tabs!

luci


On 16.1.2017 21:00, Jean-Marc Libs wrote:
I really prefer tabs because I have them exactly how wide I need them (2 spaces) so I can split stuff vertically, and whoever prefers 4 or 8 spaces can do that without bothering me.

Spaces lead to normalising how many spaces one uses per tab, which should not depend on a project, but on one's windows width.
My short opinion: Unless we all work in the same company using only company-issued hardware, spaces are not for us.

On Mon, Jan 16, 2017 at 8:17 PM, Jonny Bradley <[hidden email]> wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




> On 16 Jan 2017, at 18:10, Victor Emanouilov <[hidden email][hidden email]> wrote:
>
> I have pondered this myself - things get even more confusing for large
> libs like trackerlib or service controllers where we have a mix - large
> set of snake_case vs small set of camelCased functions. Do we have an
> agreement as to what case should the new functions be in those files?
>
> Regards,
> Victor
>
> On 01/16/2017 04:13 PM, Jonny Bradley wrote:
>>
>> +1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.
>>
>> I suggest we add another exception to the Zend standards?
>>
>> jb
>>
>>
>>
>>> On 16 Jan 2017, at 14:07, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> I hope all the other authors of the functions in that file get arrested too! ;)
>>>
>>> Yup. I was caught as well!
>>>
>>> Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.
>>>
>>> Brendan
>>>
>>>
>>>> Can you send me a link? I just followed the convention of the already existing functions in the headerlib...
>>>>
>>>> luci
>>>>
>>>>
>>>>> Other than that, I find this function counter-intuitive. Please either:
>>>>>   • Document
>>>>>   • Rename to something like "setRawHTML"
>>>>>   • Concatenate the argument to $this->rawhtml rather than overwriting
>>>>>
>>>>>
>>>>> --
>>>>> Filipus Klutiero
>>>>>
>>>>> http://www.philippecloutier.com
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Developer Access Program for Intel Xeon Phi Processors
>>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>>> With one year of Intel Parallel Studio XE.
>>>>> Training and support from Colfax.
>>>>> Order your platform today.
>>>>> http://sdm.link/xeonphi
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> Tikiwiki-cvs mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> _______________________________________________
>>>> Tikiwiki-cvs mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>>> Tikiwiki-cvs mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Tikiwiki-cvs mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Tikiwiki-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions

lindon-4
In reply to this post by Filipus Klutiero
One thing to point out is that ajax services currently somewhat forces using snake_case in that functions within the controller files must start with action_ and the rest of the function name is the submit element name. Any documentation or changes we’d decide to make would need to address this area of the code.
Regards,
lindon


On Jan 16, 2017, at 8:24 PM, Filipus Klutiero <[hidden email]> wrote:

I am not that attached to camelCase, but I do care about keeping our conventions accurate and concise.
  1. Conventions should be documented.
  2. I am reluctant to complexify our rules. Therefore, instead of saying a new function should be named according to its file's existing functions, I would find it less problematic to simply explain that large parts of Tiki do not respect our standards, and that additions to non-complying parts are not expected to comply with standards.
On 2017-01-16 14:17, Jonny Bradley wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




On 16 Jan 2017, at 18:10, Victor Emanouilov [hidden email] wrote:

I have pondered this myself - things get even more confusing for large 
libs like trackerlib or service controllers where we have a mix - large 
set of snake_case vs small set of camelCased functions. Do we have an 
agreement as to what case should the new functions be in those files?

Regards,
Victor

On 01/16/2017 04:13 PM, Jonny Bradley wrote:
+1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.

I suggest we add another exception to the Zend standards?

jb



On 16 Jan 2017, at 14:07, Brendan Ferguson [hidden email] wrote:

I hope all the other authors of the functions in that file get arrested too! ;)

Yup. I was caught as well!

Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.

Brendan


Can you send me a link? I just followed the convention of the already existing functions in the headerlib...

luci


Other than that, I find this function counter-intuitive. Please either:
	• Document
	• Rename to something like "setRawHTML"
	• Concatenate the argument to $this->rawhtml rather than overwriting


-- 
Filipus Klutiero

http://www.philippecloutier.com




-- 
Filipus Klutiero
http://www.philippecloutier.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions

Filipus Klutiero
I added a warning about old-style function names to DevTips.

On 2017-01-22 07:11, lindon wrote:
One thing to point out is that ajax services currently somewhat forces using snake_case in that functions within the controller files must start with action_ and the rest of the function name is the submit element name. Any documentation or changes we’d decide to make would need to address this area of the code.
Regards,
lindon


On Jan 16, 2017, at 8:24 PM, Filipus Klutiero <[hidden email]> wrote:

I am not that attached to camelCase, but I do care about keeping our conventions accurate and concise.
  1. Conventions should be documented.
  2. I am reluctant to complexify our rules. Therefore, instead of saying a new function should be named according to its file's existing functions, I would find it less problematic to simply explain that large parts of Tiki do not respect our standards, and that additions to non-complying parts are not expected to comply with standards.
On 2017-01-16 14:17, Jonny Bradley wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




On 16 Jan 2017, at 18:10, Victor Emanouilov [hidden email] wrote:

I have pondered this myself - things get even more confusing for large 
libs like trackerlib or service controllers where we have a mix - large 
set of snake_case vs small set of camelCased functions. Do we have an 
agreement as to what case should the new functions be in those files?

Regards,
Victor

On 01/16/2017 04:13 PM, Jonny Bradley wrote:
+1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.

I suggest we add another exception to the Zend standards?

jb



On 16 Jan 2017, at 14:07, Brendan Ferguson [hidden email] wrote:

I hope all the other authors of the functions in that file get arrested too! ;)

Yup. I was caught as well!

Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.

Brendan


Can you send me a link? I just followed the convention of the already existing functions in the headerlib...

luci


Other than that, I find this function counter-intuitive. Please either:
	• Document
	• Rename to something like "setRawHTML"
	• Concatenate the argument to $this->rawhtml rather than overwriting


-- 
Filipus Klutiero

http://www.philippecloutier.com




-- 
Filipus Klutiero
http://www.philippecloutier.com
------------------------------------------------------------------------------

-- 
Filipus Klutiero
http://www.philippecloutier.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions

lindon-4
Looks good, thanks. Made minor edits.
Regards,
lindon

On Jan 23, 2017, at 12:42 AM, Filipus Klutiero <[hidden email]> wrote:

I added a warning about old-style function names to DevTips.

On 2017-01-22 07:11, lindon wrote:
One thing to point out is that ajax services currently somewhat forces using snake_case in that functions within the controller files must start with action_ and the rest of the function name is the submit element name. Any documentation or changes we’d decide to make would need to address this area of the code.
Regards,
lindon


On Jan 16, 2017, at 8:24 PM, Filipus Klutiero <[hidden email]> wrote:

I am not that attached to camelCase, but I do care about keeping our conventions accurate and concise.
  1. Conventions should be documented.
  2. I am reluctant to complexify our rules. Therefore, instead of saying a new function should be named according to its file's existing functions, I would find it less problematic to simply explain that large parts of Tiki do not respect our standards, and that additions to non-complying parts are not expected to comply with standards.
On 2017-01-16 14:17, Jonny Bradley wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




On 16 Jan 2017, at 18:10, Victor Emanouilov [hidden email] wrote:

I have pondered this myself - things get even more confusing for large 
libs like trackerlib or service controllers where we have a mix - large 
set of snake_case vs small set of camelCased functions. Do we have an 
agreement as to what case should the new functions be in those files?

Regards,
Victor

On 01/16/2017 04:13 PM, Jonny Bradley wrote:
+1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.

I suggest we add another exception to the Zend standards?

jb



On 16 Jan 2017, at 14:07, Brendan Ferguson [hidden email] wrote:

I hope all the other authors of the functions in that file get arrested too! ;)

Yup. I was caught as well!

Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.

Brendan


Can you send me a link? I just followed the convention of the already existing functions in the headerlib...

luci


Other than that, I find this function counter-intuitive. Please either:
	• Document
	• Rename to something like "setRawHTML"
	• Concatenate the argument to $this->rawhtml rather than overwriting


-- 
Filipus Klutiero

http://www.philippecloutier.com




-- 
Filipus Klutiero
http://www.philippecloutier.com
------------------------------------------------------------------------------

-- 
Filipus Klutiero
http://www.philippecloutier.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Tiki coding conventions

Filipus Klutiero
Oops. Thanks lindon.

On 2017-01-23 20:04, lindon wrote:
Looks good, thanks. Made minor edits.
Regards,
lindon

On Jan 23, 2017, at 12:42 AM, Filipus Klutiero <[hidden email]> wrote:

I added a warning about old-style function names to DevTips.

On 2017-01-22 07:11, lindon wrote:
One thing to point out is that ajax services currently somewhat forces using snake_case in that functions within the controller files must start with action_ and the rest of the function name is the submit element name. Any documentation or changes we’d decide to make would need to address this area of the code.
Regards,
lindon


On Jan 16, 2017, at 8:24 PM, Filipus Klutiero <[hidden email]> wrote:

I am not that attached to camelCase, but I do care about keeping our conventions accurate and concise.
  1. Conventions should be documented.
  2. I am reluctant to complexify our rules. Therefore, instead of saying a new function should be named according to its file's existing functions, I would find it less problematic to simply explain that large parts of Tiki do not respect our standards, and that additions to non-complying parts are not expected to comply with standards.
On 2017-01-16 14:17, Jonny Bradley wrote:
Hi Victor and all (moving this from csv to dev list)

The conventions in Tiki have always been "variable" and i've always gone with what the surrounding code looks most like, but yes, there are libraries that are already mixed (trackers, file gals etc) where people haven't done this - and in those cases, as with new files and revamps as Luci suggested, i guess we should go with camelCase where it makes sense... (although i would go with a majority thing so will continue to use snake_case for those old libs with only a few camels...)

Certainly everything inside lib/core should be camel style i think and should stay that way.

While we're looking at this sort of thing, any feelings now about our tabs instead of spaces exception these days? I seem to remember when i last suggested we change there were a couple of people on this list who were fiercely against it? (spaces never go wrong, tabs often do)

Discuss! :)

jonny




On 16 Jan 2017, at 18:10, Victor Emanouilov [hidden email] wrote:

I have pondered this myself - things get even more confusing for large 
libs like trackerlib or service controllers where we have a mix - large 
set of snake_case vs small set of camelCased functions. Do we have an 
agreement as to what case should the new functions be in those files?

Regards,
Victor

On 01/16/2017 04:13 PM, Jonny Bradley wrote:
+1 for following the convention per file. Tiki has too much code (and not enough coders) to change everything over from snake_case to camelCase everywhere.

I suggest we add another exception to the Zend standards?

jb



On 16 Jan 2017, at 14:07, Brendan Ferguson [hidden email] wrote:

I hope all the other authors of the functions in that file get arrested too! ;)

Yup. I was caught as well!

Its good though. I was also just following the conventions in the file. I normally use that zend convention in my own code, just cause I like it :) Now that I know this tiki convention, I can keep a more watchful eye on it.

Brendan


Can you send me a link? I just followed the convention of the already existing functions in the headerlib...

luci


Other than that, I find this function counter-intuitive. Please either:
	• Document
	• Rename to something like "setRawHTML"
	• Concatenate the argument to $this->rawhtml rather than overwriting


-- 
Filipus Klutiero

http://www.philippecloutier.com




-- 
Filipus Klutiero
http://www.philippecloutier.com
------------------------------------------------------------------------------

-- 
Filipus Klutiero
http://www.philippecloutier.com

-- 
Filipus Klutiero
http://www.philippecloutier.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Loading...