Correct use of functions

[paddy_fields]

Hi, just a quick question. Should functions really be used for tasks such as in my example below? I’m attempting to use some for smaller tasks to improve readability and reduce code repetition. Or should they be used for larger tasks?

 

functions.php

function accessDenied(){

$_SESSION[‘error’] = "You cannot view that page, you wally";
header(‘location: error.php’);
exit;

}

page.php

if(!$loggedin){ accessDenied(); }

Edited August 12, 2014 by paddy_fields

[ManiacDan]

This is a fine use of functions.  The best part about functionalizing code like this early in a project is so that you can edit how "access denied" works in one place instead of 300 when you change the behavior next year.  Right now it's only 2 lines, but it could also do security logging, IP checking, karma calculations, and more.  Now that you've put it in one place, you can make those decisions later, confident that they'll be centralized.

[paddy_fields]

That's great, thank you.

 

Luckily I've realised this only 20 pages in...

 

[ginerjm]

The purpose of functions is to a) reduce the occurrence of repeating the same code in your script/projects and b) separating out a significant piece of code from the main line of your current process to make the overall code easier to read and follow along with. 

 

When you identify any 'task' that you wish to compartmentalize in order to streamline the reading of the entire code assigning a complex (or even simple) set of code to a function and then just calling that code fromt the midst of a process makes great sense.  If you have a process to accomplish that involves several distinct and separate steps a good design would be clearly break apart these steps in your code and then create a short piece of code that calls the functions to complete the task in order.  For example - to process some input vars, do some calculations, look up some db information and return a result you could break it down into functions that do each of those things.  The key is to design your functions to use the appropriate input arguments for each and then pass them from your main process. 

 

When you recognize a certain set of code that will come into use many times (or even 2-3 times) in a script/project, make that a function with arguments that allow it to be used with versatility whenever you need that to happen.  A simple version might be when you need to compare two values and return some answer that is related to them multiple times.  A function that took two input args and returned a value would be both versatile and streamlined and useful all over your project.

 

Experienced programmers are always looking for already-written (and tested) code that does what they want.  Good programmers have their own library of functions that they have developed and trust to do what they need.  For example - I use a function that I include in all of my database-related scripts to make my db connection and to select the database I wish to use.  In it I have included my credentials and as an argument I pass the dbname I wish to have selected and it returns a handle to my connection.  Of course I store this script/function outside of my web tree for maximum security.

[paddy_fields]

A very interesting and detailed explanation - thank you.

 

It's going to help massively to have this logic in my mind going forward with the project.

[paddy_fields]

With regards to accessing scripts outside of the webroot, is it safe/the correct way of doing it by just moving up a step in the directory like below?

 

Assuming you're in public_html/index.php

include_once '../db_connect.php';

Edited August 12, 2014 by paddy_fields

[ManiacDan]

That format could bite you in the future if you do multiple nested files.  The best way to do it is by utilizing the $_SERVER['DOCUMENT ROOT'] variable to start from your document root, and include based on the relation to THAT folder.  What if you have that line you posted inside yourSite/admin/users/bulkDelete.php ?  You'd include ../db_connect.php, and it would fail because yourSite/admin/db_connect.php doesn't exist.  The include path is always the "working directory" of the script you accessed, which means it's the directory of the file being called by the URL.  By relying solely on relative paths without making sure you're at the proper depth, you're not future-proof.