From: Gianluca S. <gi...@gm...> - 2008-08-22 22:33:16
|
Hi all, with the switch to PHP 5 I think we all agree on bringing more modern programming practices into our code ( OOP, patterns etc). I think it is also clear the current set of coding guidelines do not support very well that goal, being drafted when PHP had little to no support for classes. Hence, I feel the need to revise our coding guidelines, hopefully without drawing everyone into endless arguments about those aspects that are, after all, personal preferences. For this reason, I propose to stick with some existing guideline so we can skip the "create" and "discuss" steps and go straight to the "approve" one. Now, I had look around for a model we could use and overall I found a very good one in the guidelines for the Zend Framework, located at: http://framework.zend.com/manual/en/coding-standard.html They look daunting at first, but once you start using them it's easy to grasp the overall organization and apply the same schema to new code. It would be nice if other developers could have a look at the documentation and share their thought about the topic. Cheers Gianluca |
From: <pa...@qu...> - 2008-08-22 22:51:05
|
> http://framework.zend.com/manual/en/coding-standard.html > > They look daunting at first, but once you start using them it's easy > to grasp the overall organization and apply the same schema to new > code. > > It would be nice if other developers could have a look at the > documentation and share their thought about the topic. > Quick Question: Is it possible to get these guidelines in a single page/pdf or whatever. I.e. something we can reproduce and customise to suite mantis if needed, or even printout to read. OR are you more proposing we just follow their format and produce our own guidelines based on their advice? Paul |
From: Gianluca S. <gi...@gm...> - 2008-08-22 23:20:15
|
On Sat, Aug 23, 2008 at 12:50 AM, <pa...@qu...> wrote: > > Quick Question: > > Is it possible to get these guidelines in a single page/pdf or whatever. > I.e. something we can reproduce and customise to suite mantis if needed, > or even printout to read. I can find the offline package here: http://framework.zend.com/download/documentation but no pdf, which is weird given the documentation is in docbook format... > > OR are you more proposing we just follow their format and produce our own > guidelines based on their advice? I guess the more we can stick with those guidelines _as is_, the less effort will be needed for maintenance at our side. Of course we may decide to deviate somewhere, but each deviation decrease the value of inheriting existing documentation. |
From: Victor B. <vb...@gm...> - 2008-08-23 00:21:01
|
Hi Gianluca, > I guess the more we can stick with those guidelines _as is_, the less > effort will be needed for maintenance at our side. > > Of course we may decide to deviate somewhere, but each deviation > decrease the value of inheriting existing documentation. Agreed. With our current standard we typically followed another one that was already prepared with some minor changes. I'll read it over the weekend and provide feedback. Regards, Victor |
From: Micah G. <mi...@on...> - 2008-08-24 02:01:23
|
Any chance of moving Mantis to sit on top of the Zend Framework? Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com Gianluca Sforna wrote: > Hi all, > with the switch to PHP 5 I think we all agree on bringing more modern > programming practices into our code ( OOP, patterns etc). I think it > is also clear the current set of coding guidelines do not support very > well that goal, being drafted when PHP had little to no support for > classes. > > Hence, I feel the need to revise our coding guidelines, hopefully > without drawing everyone into endless arguments about those aspects > that are, after all, personal preferences. > > For this reason, I propose to stick with some existing guideline so we > can skip the "create" and "discuss" steps and go straight to the > "approve" one. > > Now, I had look around for a model we could use and overall I found a > very good one in the guidelines for the Zend Framework, located at: > > http://framework.zend.com/manual/en/coding-standard.html > > They look daunting at first, but once you start using them it's easy > to grasp the overall organization and apply the same schema to new > code. > > It would be nice if other developers could have a look at the > documentation and share their thought about the topic. > > Cheers > > Gianluca > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: <pa...@qu...> - 2008-08-24 11:11:06
|
For what purpose? I know giallu likes zend framework - when i've looked at options for moving away from adodb, only thing i've found that I think might work is ezcomponents framework. When i've looked at whether we could replace jpgraph with something (as jpgraph license doesn't fit 'nicely' with mantis), i've ended up at the pear graph module. So whilst giallu keeps mentioning zend framework, i've yet to work out what we *need* it for. Or more, what we'd be trying to fix. I know PHP pretty well, I don't personally know any of the Zend framework, so if I was coding on mantis, i'd probably use the underlying php commands. What would using the zend framework fix for you? Paul > Any chance of moving Mantis to sit on top of the Zend Framework? > > Thank you, > Micah Gersten > onShore Networks > Internal Developer > http://www.onshore.com > > > > Gianluca Sforna wrote: >> Hi all, >> with the switch to PHP 5 I think we all agree on bringing more modern >> programming practices into our code ( OOP, patterns etc). I think it >> is also clear the current set of coding guidelines do not support very >> well that goal, being drafted when PHP had little to no support for >> classes. >> >> Hence, I feel the need to revise our coding guidelines, hopefully >> without drawing everyone into endless arguments about those aspects >> that are, after all, personal preferences. >> >> For this reason, I propose to stick with some existing guideline so we >> can skip the "create" and "discuss" steps and go straight to the >> "approve" one. >> >> Now, I had look around for a model we could use and overall I found a >> very good one in the guidelines for the Zend Framework, located at: >> >> http://framework.zend.com/manual/en/coding-standard.html >> >> They look daunting at first, but once you start using them it's easy >> to grasp the overall organization and apply the same schema to new >> code. >> >> It would be nice if other developers could have a look at the >> documentation and share their thought about the topic. >> >> Cheers >> >> Gianluca >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: Micah G. <mi...@on...> - 2008-08-24 14:54:25
|
Well, I'm actually going to be deploying it for our main apps, so it would mean only needing to install it once. It would reduce the size of the Mantis codebase as well. Thank you, Micah Gersten onShore Networks Internal Developer http://www.onshore.com pa...@qu... wrote: > For what purpose? > > I know giallu likes zend framework - when i've looked at options for > moving away from adodb, only thing i've found that I think might work is > ezcomponents framework. > > When i've looked at whether we could replace jpgraph with something (as > jpgraph license doesn't fit 'nicely' with mantis), i've ended up at the > pear graph module. > > So whilst giallu keeps mentioning zend framework, i've yet to work out > what we *need* it for. Or more, what we'd be trying to fix. > > I know PHP pretty well, I don't personally know any of the Zend framework, > so if I was coding on mantis, i'd probably use the underlying php > commands. > > What would using the zend framework fix for you? > > Paul > > > > >> Any chance of moving Mantis to sit on top of the Zend Framework? >> >> Thank you, >> Micah Gersten >> onShore Networks >> Internal Developer >> http://www.onshore.com >> >> >> >> Gianluca Sforna wrote: >> >>> Hi all, >>> with the switch to PHP 5 I think we all agree on bringing more modern >>> programming practices into our code ( OOP, patterns etc). I think it >>> is also clear the current set of coding guidelines do not support very >>> well that goal, being drafted when PHP had little to no support for >>> classes. >>> >>> Hence, I feel the need to revise our coding guidelines, hopefully >>> without drawing everyone into endless arguments about those aspects >>> that are, after all, personal preferences. >>> >>> For this reason, I propose to stick with some existing guideline so we >>> can skip the "create" and "discuss" steps and go straight to the >>> "approve" one. >>> >>> Now, I had look around for a model we could use and overall I found a >>> very good one in the guidelines for the Zend Framework, located at: >>> >>> http://framework.zend.com/manual/en/coding-standard.html >>> >>> They look daunting at first, but once you start using them it's easy >>> to grasp the overall organization and apply the same schema to new >>> code. >>> >>> It would be nice if other developers could have a look at the >>> documentation and share their thought about the topic. >>> >>> Cheers >>> >>> Gianluca >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> mantisbt-dev mailing list >>> man...@li... >>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >>> >>> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> >> >> > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Glenn H. <thr...@lo...> - 2008-08-24 02:29:47
|
On 22-Aug-08, at 6:33 PM, Gianluca Sforna wrote: > Hi all, > with the switch to PHP 5 I think we all agree on bringing more modern > programming practices into our code ( OOP, patterns etc). I think it > is also clear the current set of coding guidelines do not support very > well that goal, being drafted when PHP had little to no support for > classes. > > Hence, I feel the need to revise our coding guidelines, hopefully > without drawing everyone into endless arguments about those aspects > that are, after all, personal preferences. > > For this reason, I propose to stick with some existing guideline so we > can skip the "create" and "discuss" steps and go straight to the > "approve" one. > > Now, I had look around for a model we could use and overall I found a > very good one in the guidelines for the Zend Framework, located at: > > http://framework.zend.com/manual/en/coding-standard.html > > They look daunting at first, but once you start using them it's easy > to grasp the overall organization and apply the same schema to new > code. > > It would be nice if other developers could have a look at the > documentation and share their thought about the topic. I have a few comments: 1) The file naming convention is quite different from what we use now. It seems to be useful (to me) to understand that the file defines API or class functions. 2) The function naming convention is missing the API name. This is also very useful in locating the function / method source. As we move to OOP, we probably need a convention for object instantiation that refers back to the original class name so we can make a similar traceback. 3) I like the current variable naming convention that we have that differentiates local, parameter, and global variables. It also helps ensure that we know what has global scope. ... Glenn -- Glenn Henshaw Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User |
From: John R. <jr...@le...> - 2008-08-24 23:04:05
|
Glenn Henshaw wrote: > I have a few comments: > > 1) The file naming convention is quite different from what we use now. > It seems to be useful (to me) to understand that the file defines API or > class functions. > > 2) The function naming convention is missing the API name. This is also > very useful in locating the function / method source. As we move to OOP, > we probably need a convention for object instantiation that refers back > to the original class name so we can make a similar traceback. I think as long as we stick to naming objects for the API, we shouldn't need to make the method names verbose: $t_tokens->save() VS $t_tokens->token_save() The first is much easier to read but still conveys the same information. > 3) I like the current variable naming convention that we have that > differentiates local, parameter, and global variables. It also helps > ensure that we know what has global scope. I completely agree with this part, for normal variables at least. Class/object member variables however, should have no prefix, considering they always have to be referenced by class/object: $object->member OR Class::member -- John Reese LeetCode.net |
From: Glenn H. <thr...@lo...> - 2008-08-25 01:50:48
|
On 24-Aug-08, at 7:04 PM, John Reese wrote: > Glenn Henshaw wrote: >> I have a few comments: >> >> 1) The file naming convention is quite different from what we use >> now. >> It seems to be useful (to me) to understand that the file defines >> API or >> class functions. >> >> 2) The function naming convention is missing the API name. This is >> also >> very useful in locating the function / method source. As we move to >> OOP, >> we probably need a convention for object instantiation that refers >> back >> to the original class name so we can make a similar traceback. > > I think as long as we stick to naming objects for the API, we > shouldn't > need to make the method names verbose: > > $t_tokens->save() VS $t_tokens->token_save() > > The first is much easier to read but still conveys the same > information. > >> 3) I like the current variable naming convention that we have that >> differentiates local, parameter, and global variables. It also helps >> ensure that we know what has global scope. > > I completely agree with this part, for normal variables at least. > Class/object member variables however, should have no prefix, > considering they always have to be referenced by class/object: > > $object->member OR Class::member > I agree with both of these comments. ... Glenn > -- > John Reese > LeetCode.net > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Glenn Henshaw Logical Outcome Ltd. t: (613) 853-6702 e: thr...@lo... f: (613) 832-2133 w: www.logicaloutcome.ca This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. |
From: Gianluca S. <gi...@gm...> - 2008-08-25 12:21:08
|
Hi Glenn, On Sun, Aug 24, 2008 at 4:29 AM, Glenn Henshaw <thr...@lo...> wrote: > 1) The file naming convention is quite different from what we use now. It > seems to be useful (to me) to understand that the file defines API or class > functions. IMHO new code should not pollute anymore the global namespace that is, all functions should be either static methods ( Class::method() ) or regular objects methods: Object->method() > 2) The function naming convention is missing the API name. This is also very > useful in locating the function / method source. As we move to OOP, we > probably need a convention for object instantiation that refers back to the > original class name so we can make a similar traceback. We just need to rethink how we determine this info, for instance: old convention: string_display_line() -> core/string_api.php new convention: class Mantis_String -> core/Mantis/String.php besides, try guessing where is print_manage_menu() ? > 3) I like the current variable naming convention that we have that > differentiates local, parameter, and global variables. It also helps ensure > that we know what has global scope. That naming convention is really useful when you have longer functions and you risk to fail remembering where $variable come from. In the brave new world, I don't think we need to use prefixes because: 1. global variables (g_) should not exists 2. functions should be short enough to make the local/parameter distinction useless However, guidelines says protected and private class members should be prefixed with _ for an easier recognition: http://framework.zend.com/manual/en/coding-standard.naming-conventions.html#coding-standard.naming-conventions.variables Cheers Gianluca |
From: Victor B. <vb...@gm...> - 2008-08-26 01:57:55
|
I've reviewed the Zend Framework coding conventions and it looks really good. Although I hate to change conventions, I'm totally on board with the fact that to really move to PHP5 and OO, we will need to revise our standards, and hence, I think to use this one sounds like a good idea. As for the transition and some other process relating remarks that I had in mind, here are some comments: 1. Plugin framework - As we change the class names and API files / names, we will break plugins. There are areas that are more likely to be used by plugins than others (e.g. plugin base classes). We need to brainstorm on this a little bit to come up with the best course of action. 2. Class Names - The class names depend on the directory structure in ZF. However, for Mantis, I think it should depend on the components. For example, Mantis_Core_Xyz. This matches the current directory structure, but if we move core to somewhere else, then it continues to be Mantis_Core_Xyz since it still remains part of the "core" logical component. 3. SOAP API - Ideally the SOAP API will not be broken by renames to its methods or structures. If we want to change to the new standard, we should consider a compatibility layer. 4. Auto Include - If we are going to use the auto include feature of PHP, we should verify that the class naming conventions / file names / file location are as expected. If would expect that ZF team has already thought of this, but my suggestion for 2 may break it. If so, then we should re-think 2. 5. In Place Upgrade - We should update admin/check.php to check for obsolete file names and surface them to the user. As we are moving / renaming files, in place upgrades will cause a big mess. We should help users to avoid / fix such mess. 6. Exceptions - Core classes should use exceptions rather than output errors directly. 7. Model - The model classes should not include any code that prints or formats output. 8. Unit testing - With a pure model and use of exceptions we should be able to implement unit tests. 9. Templates - As we are re-structuring Mantis, we should consider our plans to move to MVC / templates. 10. Custom Functions - Needs to be re-designed. 11. Build - Implement a build script which runs unit tests, compiles docbook, pushlishes snapshots, sends emails with failures, etc. 12. Automate the running of the build (e.g. run once a day when there are checkins). 13. Incremental Approach - We should set clear targets and incrementally move towards them. I don't want to create branches that get obsolete and abandoned. We can clean up one API at a time, change client code to use it, implement unit tests, etc. 14. No Framework (for now) - We already have a lot of work as is, I don't think we should move to ZF as an underlying framework (or any other) for now. Obviously if we make a decision to move to a framework like CakePHP rather than ZF, then following ZF standard is really a waste of time :). On Mon, Aug 25, 2008 at 5:21 AM, Gianluca Sforna <gi...@gm...> wrote: > Hi Glenn, > > On Sun, Aug 24, 2008 at 4:29 AM, Glenn Henshaw > <thr...@lo...> wrote: > > 1) The file naming convention is quite different from what we use now. It > > seems to be useful (to me) to understand that the file defines API or > class > > functions. > > IMHO new code should not pollute anymore the global namespace that is, > all functions should be either static methods ( Class::method() ) or > regular objects methods: Object->method() > > > 2) The function naming convention is missing the API name. This is also > very > > useful in locating the function / method source. As we move to OOP, we > > probably need a convention for object instantiation that refers back to > the > > original class name so we can make a similar traceback. > > We just need to rethink how we determine this info, for instance: > > old convention: string_display_line() -> core/string_api.php > new convention: class Mantis_String -> core/Mantis/String.php > > besides, try guessing where is print_manage_menu() ? > > > 3) I like the current variable naming convention that we have that > > differentiates local, parameter, and global variables. It also helps > ensure > > that we know what has global scope. > > That naming convention is really useful when you have longer functions > and you risk to fail remembering where $variable come from. > > In the brave new world, I don't think we need to use prefixes because: > > 1. global variables (g_) should not exists > 2. functions should be short enough to make the local/parameter > distinction useless > > However, guidelines says protected and private class members should be > prefixed with _ for an easier recognition: > > http://framework.zend.com/manual/en/coding-standard.naming-conventions.html#coding-standard.naming-conventions.variables > > Cheers > > Gianluca > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Gianluca S. <gi...@gm...> - 2008-09-07 23:20:25
|
On Tue, Aug 26, 2008 at 3:57 AM, Victor Boctor <vb...@gm...> wrote: > I've reviewed the Zend Framework coding conventions and it looks really > good. Although I hate to change conventions, I'm totally on board with the > fact that to really move to PHP5 and OO, we will need to revise our > standards, and hence, I think to use this one sounds like a good idea. Thank you Victor for reviewing the guidelines. I think we never really decided how to handle such decisions (i.e. no voting or anything formal) so I'll assume we can start using the guidelines as soon as there is a new class to be written. we need to update the references about coding guidelines we have in the web-site/wiki; any takers? I will to move on another thread to discuss your specific points about how to proceed with the transition. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |