Hello,
I am wondering if it's a bad thing to create a large PHP app based on one file!
What would be the cons & pros?
Thank you.
| SitePoint Sponsor |
Hello,
I am wondering if it's a bad thing to create a large PHP app based on one file!
What would be the cons & pros?
Thank you.
Why It Doesn't Work?!
Cons:
1. processing overheads
2. maintenance hassles
3. development hassles
4. i dont think you can even edit a text file that large in any editor
Pros:
Can't think of any.


There are lots of editors that can handle a 1MB file
Other than that, I would tend to agree with bigduke. There's no big benefit to having your entire application in one file... well, I guess it makes backups a little easier. You are much better off including or requireing sepearte files into your application as needed, unless of course everytime the application is run it requires everything.
In the end, you're app will use less CPU/memory and run faster if you only include what is needed for that run.
Reduce or eliminate spam on your sites without CAPTHCAs
- maybe it is possible: http://formantispam.thekerrs.ca/
IMO it may be a good idea to store core classes (called every run of application) in one file. That can provide better performance than including each file separately.
The only problem is ugly, hard-to-read code.
On other forum we came up with an idea to create parser, that merges selected files into one, removes local requires and includes, etc., however AFAIK the project is dropped.



It's very poor organisation to put all code in one file. It also becomes tedious to find the source of errors.
That's why I said about parser to merge files. Personally, I'd never put all code in one file - it'd be mortyfing...Originally Posted by N9ne
OK almost forgot to highlight this, you change ONE character in your file and you have to upload 1 MB of data. Now unless you were running the script off your machine or have a super-BB conn (for which i'd hate you) its a big-time waste of resources. Not to mention that the overall code structure will get distorted way beyond recognition and the performance loss while parsing such a humungous file.
What about a 300kb file?
I've finished coding the core API to a project I'm working on and its come to just over 300kb, it's in one file but has no noticeable speed decreases and all tests have shown it to run efficiently.
Someone once taught me that each file should have no more than 400 lines of code, and if it does, you need to extract that a bit into helper files.
Sara
400? I think that's too little.
My current API has 6,000 lines.
con: Shared hosting may not be an option or at least a very long term option.
Looking through a couple of my sites... the biggest php file I could find was about 19kb just over 600 lines of code with three includes. However, it's admin page so it gets very little traffic. My php files seem to average 8-9kb before stripping whitespace and comments.


Originally Posted by Dale_C
.
My image gallery so far has 21 lines, and it is already bugging out.
Mind you, I do have about 6 classes in this file so I could probably re-structure it better. Also I think I've ended up re-writing a few methods because I sometimes forget I've already written a piece of code![]()
I also use a lot of white space as you can see in the screenshot, I like to separate each class, each method etc. so it's easier on the eye.
My top is about 600 lines, and that's for a single class that just happened to have a massive task in front of it. The thought of having more than that is kind of sickening.
- Nathan
LOL a really cool thread...
My image gallery so far has 21 lines, and it is already bugging out ..




like bigduke said, you would be including code that probably isn't used on EVERY page, so theres the processing overhead
and also debugging would b hard as you hav to find the rite lines to edit and upload everytime
Smaller is better... much better.
From a QA standpoint, if you touch a line of code in a module (file), you must test every bit of functionality in that module... in your case, the entire application would have to be retested for, say, a change in the copyright line.
If you compartmentalize appropriately, then even changes to core fuctionality only require testing of parts that function, and not the entire application. Well, that doesn't sound quite right, but you get the drift.
Smaller is better.
PS With that much code, there MUST be opportunity for replacing redundant functionality with functions, no? You launching a Space Shuttle over there?![]()
Not sure if you were talking to me, my API only comes to 200kb, it's 6000 lines but the code is actually fairly efficient I just have many, many different functions.
The project I'm working on deals with a hierarchical referral system, it's got a news portal, user/business profile management, mailing list management, business/member directories, forum, private messaging system. It's a fairly large project so I think 200kb to handle that amount of functionality isn't THAT bad when considering a commercial forum is usually collectively over a 1000kb.





No, I think this is a stupid idea because editing it would be much harder since you would have to search for specific sections of the file. Better to splice it up into many smaller files.
<kidding> what the bloody devil did you write in 6000 lines ? "I <3 PHP"</kidding>



con: if you have one error in the app, then it's in that file and everything has to be working for the app to actually function.
I think it depends on requirement.
But it is not usual if someone write 1 MB code in 1 file PHP.
If you create good scripting, maye easy to trace if get some error![]()

pros:
- it's self contained
cons:
+ performance/scalability:
++ consumes more memory
++ takes longer to compile
++ is slower
+ maintenance is harder
++ readability is worse
++ handling is harder
Also the proximity of the code may lead to coding with less encapsulation and more entangled and dependent segments, which is bad for maintenance, extensibility and more error-prone. Switching between different files/tabs while editing is IMHO a good reminder that makes you aware of dependencies.
Maybe Angry Coder meant with one file an index.php. I think this would be possible. If the site isn't too big. you could still have liberaries to back you up, but only one file that is sent to the browser (maybe with a query-string). In this page you could have a case structure, defining how your page would have to look


How about collaboration in projects? Many developers working on the same file?!?
<yoda-speech>
Exists such an IDE I think not.
</yoda-speech>
Bookmarks