Need to be submitted to Core Development Team for approval and placement
into the roadmap now. New major features will be frozen once this roadmap is finalized.
Additional Features (Minor):
Send to list for discussion
A minor feature would be: "Hey, can we have font sizes be dynamic and pulled from
the vars table like evertyhing else" A major feature would be:
"Hey, can we have a real-time chat engine too?"
Major features for MyPhpMoney will not be allowed once this roadmap is finalized,
unless it is absolutely warranted. Speak up now about
what you want to see in MyPhpMoney now or you'll have to wait a while.
If you're unclear as to what something means, ask..
I don't want any mis-communication about stuff later.
Minor features will be handeled as normal unless deemed "major" by the Core Team and get back burnered.
Contributed code will still be reviewd as per the guideleines in the FORUM DEVELOPER
I'm sorry to have to clamp down on features like this, but I feel we need direction and a clear path for development. Having goals that are set and tangible will help us all stay focused and working. I also think that the feature list here is quite comprehensive and would certianly kick the ass of any other weblog out there, current or future..
API Change Policy:
Will be handled after 0.6, suffice to say, keep it abstracted, clean and quick.
Use C-Style /* */ and // comments only. # Should be phased out
Use // for in code comments, but /* */ for headers and multi-line comments (ie: trning off Debug features)
Always include your initals or cvs username (if you have one) and preferably your email address if it is not in the CREDITS file
Please leave intelligent notes in comments. Refrain from: /* I'm gonna do something cool, don't change this */ A better way is: /* nh: Don't touch, I'm working on making the fliberty thing flip as * well as spin - Apr, 9, 2000 */
Please leave comments for things that are not self evident (esp. for Regular Expressions)
Functions / Objects:
Should be well commented as to their arguments, what they do and how they work. This should take place on the lines preceding the function decleration.
Should be as minimalistic as possible. If it can be bnroken into two functions, please do so.
Wrapper functions to provide multiple methods of output are highly recommended.
Variable Naming:
Hungarian Notation is prefered for things that are gloablly accessable. Private variables for objects and functions should be named to something indicative of what they do. No cutesy crap that we'll all forget in 6 months.
Keep it short, but not incomprehensable. $tmp_cnt is better than $temporaryVariableThatIsACounterForMeRightNow and better than $t
Mixed case ($tmpCnt) or underscore ($tmp_cnt) usage only?
Whitespace:
USE IT!!!!
Just becasue you can write a complex one-liner doesn't mean you have to. Take the extra lines and use curly braces.
Indent level of 3
No tabs anywhere, spaces only.
For Example:
someFunction() {
if ($someVar) {
doOtherFunction();
} else {
error("You *are* stupid! Don't do that");
}
}
======================================
Module / Class / Include file Format:
======================================
Should start with a line(s) that tells a reader what it is, what package it comes from,
what it does, CVS $Id:$ line
Templates are an execption to that above rule. They should have an HTML comment in them that points their ownership to a class
Setup any neeed variable first, then include() files, then declare functions, then page processing, then page output.
Docs:
Always alert the doc maintainer when importing changes that break the info covered in the docs.
DB:
Changes to the main db schema *require* a that an upgrade patch be posted as well. Your change will be backed out if you don't provide a patch as well.
Debug:
Leaving debug code in is ok for experimental features, please make sure you submit your code with debug turned off / commented out though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
====================
Feature Policy:
====================
Need to be submitted to Core Development Team for approval and placement
into the roadmap now. New major features will be frozen once this roadmap is finalized.
Additional Features (Minor):
Send to list for discussion
A minor feature would be: "Hey, can we have font sizes be dynamic and pulled from
the vars table like evertyhing else" A major feature would be:
"Hey, can we have a real-time chat engine too?"
Major features for MyPhpMoney will not be allowed once this roadmap is finalized,
unless it is absolutely warranted. Speak up now about
what you want to see in MyPhpMoney now or you'll have to wait a while.
If you're unclear as to what something means, ask..
I don't want any mis-communication about stuff later.
Minor features will be handeled as normal unless deemed "major" by the Core Team and get back burnered.
Contributed code will still be reviewd as per the guideleines in the FORUM DEVELOPER
I'm sorry to have to clamp down on features like this, but I feel we need direction and a clear path for development. Having goals that are set and tangible will help us all stay focused and working. I also think that the feature list here is quite comprehensive and would certianly kick the ass of any other weblog out there, current or future..
API Change Policy:
Will be handled after 0.6, suffice to say, keep it abstracted, clean and quick.
====================
Coding Style:
====================
Comments:
Use C-Style /* */ and // comments only. # Should be phased out
Use // for in code comments, but /* */ for headers and multi-line comments (ie: trning off Debug features)
Always include your initals or cvs username (if you have one) and preferably your email address if it is not in the CREDITS file
Please leave intelligent notes in comments. Refrain from: /* I'm gonna do something cool, don't change this */ A better way is: /* nh: Don't touch, I'm working on making the fliberty thing flip as * well as spin - Apr, 9, 2000 */
Please leave comments for things that are not self evident (esp. for Regular Expressions)
Functions / Objects:
Should be well commented as to their arguments, what they do and how they work. This should take place on the lines preceding the function decleration.
Should be as minimalistic as possible. If it can be bnroken into two functions, please do so.
Wrapper functions to provide multiple methods of output are highly recommended.
Variable Naming:
Hungarian Notation is prefered for things that are gloablly accessable. Private variables for objects and functions should be named to something indicative of what they do. No cutesy crap that we'll all forget in 6 months.
Keep it short, but not incomprehensable. $tmp_cnt is better than $temporaryVariableThatIsACounterForMeRightNow and better than $t
Mixed case ($tmpCnt) or underscore ($tmp_cnt) usage only?
Whitespace:
USE IT!!!!
Just becasue you can write a complex one-liner doesn't mean you have to. Take the extra lines and use curly braces.
Indent level of 3
No tabs anywhere, spaces only.
For Example:
someFunction() {
if ($someVar) {
doOtherFunction();
} else {
error("You *are* stupid! Don't do that");
}
}
======================================
Module / Class / Include file Format:
======================================
Should start with a line(s) that tells a reader what it is, what package it comes from,
what it does, CVS $Id:$ line
Templates are an execption to that above rule. They should have an HTML comment in them that points their ownership to a class
Setup any neeed variable first, then include() files, then declare functions, then page processing, then page output.
Docs:
Always alert the doc maintainer when importing changes that break the info covered in the docs.
DB:
Changes to the main db schema *require* a that an upgrade patch be posted as well. Your change will be backed out if you don't provide a patch as well.
Debug:
Leaving debug code in is ok for experimental features, please make sure you submit your code with debug turned off / commented out though.