Enterprise Level Development
Moderator: General Moderators
Enterprise Level Development
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?
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?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
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...
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...
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.
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.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.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
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.
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.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
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.
(#10850)