Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
switch ($type) {
case 1:
//LOTS OF CODE
break;
case 2:
//LOTS OF CODE
break;
case 3:
//LOTS OF CODE
break;
case 4:
//LOTS OF CODE
break;
case 5:
//LOTS OF CODE
break;
}
What would be the advantages and disadvantages of breaking it up into:
switch ($type) {
case 1:
require_once("code1.php");
break;
case 2:
require_once("code2.php");
break;
case 3:
require_once("code3.php");
break;
case 4:
require_once("code4.php");
break;
case 5:
require_once("code5.php");
break;
}
The code is being added every day, so the PHP file will grow to 400 Kb soon. Any suggestions?
including only the functionality you need will save you both cycles and memory...so modularity in PHP makes sense...
Organziation of code...easier when modular....plus no one likes to look at functions or scripts in the thousands of lines...a few hundred at most per function is ideal...
the minute a function or module starts pushing the 1000 line boundry...I would almost gaurantee it's time to refactor...divide and conquer...and decompose your problems a little more.
A problem which is explained in more than a 1000 lines...is no longer atomic and is likely composed or more than a single "problem" per se...
Modularity has the only side effect of having to work on multiple files concurrently...which some might argue is confusing...but I say...no more confusing than having your mind have to jump back and forth while inside a single large file.
including only the functionality you need will save you both cycles and memory...so modularity in PHP makes sense...
Organziation of code...easier when modular....plus no one likes to look at functions or scripts in the thousands of lines...a few hundred at most per function is ideal...
the minute a function or module starts pushing the 1000 line boundry...I would almost gaurantee it's time to refactor...divide and conquer...and decompose your problems a little more.
A problem which is explained in more than a 1000 lines...is no longer atomic and is likely composed or more than a single "problem" per se...
Modularity has the only side effect of having to work on multiple files concurrently...which some might argue is confusing...but I say...no more confusing than having your mind have to jump back and forth while inside a single large file.
Cheers
wow.... a function pushing 100 rows is a disaster... and a 1000...pfew, nightmare.
Organziation of code...easier when modular....plus no one likes to look at functions or scripts in the thousands of lines...a few hundred at most per function is ideal...
I peg the ideal function/method body length at 20-30 lines excluding comments (me likes comments ). The issue is that a long method is long because it is usually handling more than 1 discrete parcel of logic. It's far more readable to break such logic parcels into separate private methods (or other external functions if procedural) with a descriptive name to aid readability.
Back on topic.
A function with thousands of lines is going to be incredibly difficult to maintain. I definitely suggest breaking it up into smaller pieces.
Maugrim_The_Reaper wrote:
I peg the ideal function/method body length at 20-30 lines excluding comments (me likes comments ). The issue is that a long method is long because it is usually handling more than 1 discrete parcel of logic.
I comment like crazy...so source folding is a really nice feature...but yea I'm around that same count excluding comments...