Leaderboard

That's far too restrictive and either something that was misunderstood or came from a crazy person. I came across a rule of thumb some time ago that I try to live by which goes a little something like this: A function should fit entirely on screen (no vertical scrolling required). How many lines this is will vary based on resolution/fonts and such, but ends up being around 65 lines for my environment. A single line shouldn't be longer than the width of the screen (no horizontal scrolling required). That ends up being around 120 characters for me. A function shouldn't have statements nested more than 5 levels deep Use a descriptive name for the function even if it's verbose. As with many things those are rules of thumb and not everything will conform to them, but I find they are generally pretty easy to follow. If you end up breaking one of them, then it's time to analyze the situation and decide if you need to break the rule or if it can be refactored. For rule #1, some things I only consider to be one line because they can be easily code-folded away. For example I have many functions that are way more than 65 lines, but a lot of those lines are a large SQL statement that I can just fold down to a single line. Rule #3 helps make rule #2 easier to hit as you don't waste a bunch of screen real estate indenting things a bunch. Something nested 5 levels with a 4-space indent would be wasting 20 characters on the indentation. In my experience, refactoring old code to help fit the above rules is relatively simple. Start by just moving blocks of code, for example move the body of a loop into a new function then call that function from the loop. Alternatively, just move the entire loop and replace it with a function call. Having a bunch of functions in a single file isn't necessarily bad. It'd be best to at least group them in some way rather than just dump everything in one file. For example, I have a few functions that deal with manipulating arrays which are all grouped together in a file. Some other functions that handle validating input are in a separate file. If you want to do one function, one file like with classes that's fine as well but not generally necessary imo.

I haven't seen a lot of your code, but the other thing that jumps out is that having functions where you are passing 4-5 parameters indicates that you probably have blocks of code that are trying to do too many things, and are not discrete enough. I certainly could look back at code I wrote in the past and admit I did the same thing on many occasions. This leads to the type of problems you are concerned about: large code base, concerns over side effects if you make a change, cascading throughout the code, lack of DRYness etc. This tends to happen when you build everything from scratch, as your code evolves into a thing "that works for what I have" rather than something designed from the outset to be clean and maintainable, and unit testable. While you can't go back and change large swaths of the system now, you certainly can improve it incrementally by writing smaller more discrete functions for anything new or currently undergoing modification, and refactoring whenever possible. Sometimes a small improvement can be game changing in terms of system quality and maintainability. Write functions that do one thing, and always return a result of the same type. Most functions should have a handful of parameters. If there are more than a few essential parameters, look at ways to break the function into smaller more discrete functions/pieces that you can use to assemble your results Obviously having functions with 1000's of lines of code is hard to work with. Most editors have ways to open multiple windows and add bookmarks in your code, when you have to move from one to another. Some of the fancier IDE's also let you jump back and forth in your code, by creating linkages from the files where classes and functions were defined that the editor can then use to open the appropriate file when needed, akin to clicking on a hyperlink. PHPStorm has that type of function, and can really help when navigating a large codebase.

Defining a function with optional parameters is done the way you did it. <?php function foo($bar, $fruit=null, $candy=null) { echo "bar: $bar" . PHP_EOL; echo "fruit: $fruit" . PHP_EOL; echo "candy: $candy" . PHP_EOL; } foo('one bar'); foo('one bar', 'apple'); foo('one bar', null, 'snickers'); With basic functions, all parameters are passed by value, not pass by reference. $error = array('message' => ''); function testparams($msg, $error) { $error['message'] = $msg; } testparams('BAD SYSTEM', $error); // Original error array was not changed, because it was copied internal to the function echo "Error: {$error['message']}" . PHP_EOL; To get around this, you can tell PHP that the $error array should be passed by reference, and change the original array variable. $error = array('message' => ''); function testparams($msg, &$error) { $error['message'] = $msg; } testparams('BAD SYSTEM', $error); echo "Error: {$error['message']}" . PHP_EOL; // Result is Error: BAD SYSTEM

$_POST will normally always have values for each element in the form. However, some of the values may be "empty". So you would need to use 'empty' on each element rather than the entire array. As an aside, although it will not do what you want, based on the code comments your 'if' block should be: if (!empty($myArray)){ // Handle array }else{ // Handle empty array }

Make an array of the required form fields in php, then loop through that array on submission. If any of the fields are empty, add a message to an errors array. In the end of the actual, full form processing script if the errors array isn't empty, loop through the errors array and print out each individual error.

XAMPP is fine, sure. The point is that you're complaining about the hassle of having to upload files to some server somewhere every time you want to make a change. Well, you know what the easiest way to see changes is? If you don't have to move the files anywhere. Don't bring the files to the server. Bring the server to the files.