Page 1 of 1
Enterprise Level Development
Posted: Mon Jun 26, 2006 4:22 pm
by Benjamin
I am 95% done on a very, very large website. I didn't code it using OOP but it is very centralized code. Anything that happens in more than one place can be modified in the function.php file.
This file (functions.php) is now about 6000 lines of code. Is it bad for every page to pull this function file, even though most of the pages don't require many of the functions?
Posted: Mon Jun 26, 2006 4:25 pm
by feyd
Test it. On some platforms, it can be faster to have a unified file and on others, better to have many smaller files.
Posted: Mon Jun 26, 2006 4:29 pm
by Benjamin
By testing it do you mean take one of the pages and recode it so that instead of pulling the function file it has all the functions it needs included in itself? I can't see how that wouldn't be faster.
Posted: Mon Jun 26, 2006 4:32 pm
by feyd
There are three things for you to test:
- One large include
- many smaller includes
- directly include only the functions needed in the page (this is generally less important because you want it to be more modular)
Posted: Mon Jun 26, 2006 4:36 pm
by Benjamin
K Got it, I'll do that when I start benchmarking the site.
Posted: Mon Jun 26, 2006 7:03 pm
by alex.barylski
The answer is subjective...
In general...yes...in a language like PHP where every included file is *tokenized/parsed* having a 6,000 line module included eveytime when only 10% or whatever is used on any given page...
It's a waste of resources, both CPU and RAM...
Defeats the saying "divide and conquer"...
It's ultimately personal choice...
Posted: Mon Jun 26, 2006 7:50 pm
by patrikG
interpreting what hockey said: it depends on what you want to achieve.
6000 lines in one file is almost malicious in my book.
I am not writing code for the computer, I am trying to write code that is maintainable. To me, that includes short functions (or methods) (maximum 1 screen), clear separation of business logic and presentation (at the very least), a clear & concise naming policy (descriptive names rather than abbreviations), phpDocumentor-compatible comments and, as a rule of thumb, classes not longer than maximum 500 lines & no deep inheritance, no references in functions to globals or superglobals.
If you had finished the project next week and came back to it in six months: would you be able to maintain it without headaches? If the answer is no, rethink your development process. If you think, yes, maybe, but only I would be able to, no-one else: rethink your develpment process.
Posted: Mon Jun 26, 2006 8:27 pm
by Benjamin
patrikG wrote:interpreting what hockey said: it depends on what you want to achieve.
6000 lines in one file is almost malicious in my book.
I am not writing code for the computer, I am trying to write code that is maintainable. To me, that includes short functions (or methods) (maximum 1 screen), clear separation of business logic and presentation (at the very least), a clear & concise naming policy (descriptive names rather than abbreviations), phpDocumentor-compatible comments and, as a rule of thumb, classes not longer than maximum 500 lines & no deep inheritance, no references in functions to globals or superglobals.
If you had finished the project next week and came back to it in six months: would you be able to maintain it without headaches? If the answer is no, rethink your development process. If you think, yes, maybe, but only I would be able to, no-one else: rethink your develpment process.
Thank's for your comment, the site is very easy to maintain, it's just complex and large.
Posted: Mon Jun 26, 2006 8:31 pm
by RobertGonzalez
have been trying to think of something to add to this thread all day, but have been at a loss for words. But now that I have had a chance to think about it, I would probably tend to make the code a little more modular. What I mean by this is that, when you say that each page will not have a need for all the code, maybe make a series of includes that can act as page support includes. When needed, include them. Otherwise, let them sit quietly on the sidelines until needed.
It just seems like a lot of unnecessary code per page to have a 6000 line file that does not actually do anything on the page that is calling it.
Posted: Mon Jun 26, 2006 8:32 pm
by alex.barylski
Thank's for your comment, the site is very easy to maintain, it's just complex and large.
I know what you mean...but that sounded kinda funny...oxymoron-ish
Like Military intelligence...or...pretty ugly
Cheers

Posted: Tue Jun 27, 2006 2:21 am
by Christopher
I really don't think the file layout of a site really matters that much if the code is well designed. Breaking code into separate files can help organize, identify cruft, and probably promote reuse -- but only if the programmer is focused on those things. If the programmer can manage things all in one file, then it should be fine.
But the big question we all have about our code is: "is it well designed?"
Obviously a 6000 line file is a bad code smell or you would not be asking the question of whether it is ok or not. You say the code is "centralized" (which is not a programming term that I know of) and that it is easy for you to maintain. Not much for us to go on. The only way to answer the "well designed" question is peer review. And, you don't say if you are having any performance problems including that file, so we don't know if there is an actual problem.
6000 lines is not that large of a file. I have traced through the startup of many PHP frameworks and they often include a ton of code. Try to get a framework running from a clean slate and you will be surprised at how much code they include.