CODEWITHSUNDEEP
phpapi
k4kuz0
k4kuz0

Reputation: 1045

Should a very long function/series of functions be in one php file, or broken up into smaller ones?

At the moment I am writing a series of functions for fetching Dota 2 matches from the Steam API. When someone fetches their games, I have to (for my use) take a history of all of their games (lets say 3 api calls), then all the details from each of those games (so if there's 200 games, another 200 api calls). This takes a long time, and so far I'm programming all of the above to be in one php file "FetchMatchHistory.php", which is run by the user clicking a button on the web page.

Another thing that is making me feel it should be in one file, is that I imagine it is probably good practice to put all of the information (In this case, match history, match details, id's etc.) into the database all at once, so that there doesn't have to be null values in the database?

My question is whether or not having a function that takes a very long time should be in just one PHP file (should meaning, is generally considered good practice), or whether I should break the seperate functions down into smaller files. This is very context dependent, I know, so please forgive me.

Is it common to have API calls spanning several PHP files if that is what you are making? Is there a security/reliability issue with having only one file doing all the leg-work (so to speak)?

Upvotes: 0

Views: 69

Answers (2)

user1299518
user1299518

Reputation:

Good practice is to have a number of relevant functions grouped together in a php file that describes them, for organize them better and also for caching reasons for the parts that get updated more slowly than other. But speaking of performance, i doubt you'll get the performance improvements you seek by just moving code through files.

Personally i had the habit to put everything in a file, consistently:

  • making my files fat
  • hard-to-update
  • hard-to-read
  • hard to find the thing i want (Ctrl+F meltdown)
  • wasting bandwidth uploading parts they did not need to be updated
  • virtually disabling caching on server

I dont know if any of the above is of any use for your App, but breaking files into their relevant files/places did my life easier.

UPDATE:

About the database practice, you're going to query only the parts you want to be updated. I dont understand why you split that logic in files, there's not going to give you performance. Instead, what is going to give you performance is to update only the relevant parts and having tables with relevant content. Speaking of multiple tables have a lot more sense, since you could use them as pointers to the large data contained in another tables, reducing the possible waste of data having just one table.

Also, dont forget a single table has limitations; I personally try to have as few columns as possible. Adding more and more and a day you can't add more because of the row limit. There is a maximum number of columns in general, but this limit rarely ever get maxed by developer; the increased per-row content itself is going to suck out that limit.

Upvotes: 2

MarcoS
MarcoS

Reputation: 17711

Whether to split server side code to multiple files or keep it in a single one is an organizational issue, more than a security/reliability one...

I don't think it's more secure to keep your code in separate source files.

It's entirely a of how you prefer to organize and mantain your code base.

Usually, I separate it when I can find some kind of "categories" in my code.

Obviously, if you write OO code, the most common choice is to keep each class in a single file...

Upvotes: 0

Related Questions