This is a post about a few thoughts about programming practices. These thoughts arose after my involvement with two projects.
The first project was a web application using PHP as the server-side language and MySQL as the database. A colleague came to me asking for some help in their project and hints about it. After going through some of the code and regarding my relatively little programming experience (I'm not a full time programmer), some random thoughts came to mind.
Writing in 2015 in pure PHP is probably a bad thing to do. Why? Because there are so many web frameworks today that help you a great deal in structuring your code. When you are asked to provide help and tips about some PHP pages that do ALL the stuff inside a single page, you literally don't know where to begin. Why? Because all the presentation and business logic is hidden between HTML tags and JavaScript code and you are lost. You end up having to go through a page of 2500 or more lines of code, where complex structures reside, like have this table echo-ed if this condition is true or echo this other thing if false. A modern PHP framework would probably use the MVC design pattern (as most do), where there are separate responsibilities that separate the code in pure presentation logic (HTML and JavaScript code) and business logic (ORM classes that interact with the database, retrieving, storing, updating data). If you've worked for some time with such a framework (it does not matter which one it is, most of them are pretty decent to get the job done) and you go back to a project where single page PHP files are the rule, you are stuck or lost and don't know where to begin. I read somewhere that you will appreciate frameworks after you write a LOT of bad code (bad code meaning code that uses such practices as the ones I describe here).
No use of modern libraries. When looking at the code of this first project, I see many document.getElementById("id") code that is the standard way to get access to a DOM element from JavaScript. Ok, this it not necessarily bad, but compare this:
document.getElementById("id")to this:
$('#id')Which is much shorter to write and much cleaner. Of course, the second line is the shorthand for a element selector by id in jQuery. But what is jQuery? jQuery is a JavaScript library that makes the web developer's life A LOT EASIER! You write code that is browser independent, without any quirks, code that is damn well tested and helps you do pretty useful stuff with JavaScript, like animations, DOM manipulation, AJAX calls, etc. After you read a bit about it, use it for a while in a project of yours, you will appreciate the power that comes with it. Forget about the onclick event handlers that reside in the HTML source code and you have to go through every line of code to see where this event handler is defined or called. All JavaScript (jQuery) code exists at the same place. Another separation of application and presentation responsibilities.
The second project was another web application that is used in production and was given to us to adjust it to our needs. Another case of PHP with MySQL. This project was smaller than the first one, with respect to the size of code or application complexity. It was not after importing the database dump and going through the code that the "issues" arose once again.
At my PHP/MySQL installation, I have most strict modes for both of them. What I mean is that in php.ini, the error_reporting is set to E_ALL. In MySQL (actually MariaDB), the sql_mode parameter in my.ini is set to rather strict mode and mostly close to the SQL standards, as I think it should be. OK, but what happens when you deploy a application that did not use such strict modes? You get a lot of warnings and notices. Actually, this is a very bad programming practice that both PHP and MySQL (or any fork that is) encourage (more on these later). The developer who wrote this application did not use such strict modes, so they did not get any indication of warning or notice (remember, not errors, because the application would simply fail in such a case). But since, I'm the bad guy who is stubborn and wants to use "valid" code, I had to sit down and correct all these notices and warnings, so that the application works in every PHP server (since if it works for E_ALL, it will also work for error reportings with E_NOTICE or E_WARNING disabled). The same applies for MySQL too.
On the other hand, I was glad to realize that this developer used jQuery and I was really happy with that. Still, mostly the same single page PHP application, but since the number of PHP source code lines is relatively small, I'd say that it's ok. Should a framework be used in this project? Maybe, maybe not. One might consider a framework overkill for a single PHP page application and I might agree. If you are used to working with a framework and are very happy with it, you might consider writing this using your favorite framework.
After working with this project, this question came to mind many times: "Should I write this from scratch using Yii (the framework I personally use)?". Why? Because, I had to fix all HTML code to make this application HTML valid (using the W3C validation page). Yes, I'm stubborn and I want every application of mine to adhere to standards, but I can't help it, blame me for this. I also had to put some var_dump()'s here and there to see the output of some variables for code that did not seem to work, or open the console browser window and check for any JavaScript errors since something did not work as it should. Oh well.
Now. Let's visit the PHP and MySQL front. Both are very very very widely used. Did I mention how much widely they are used? No? Well, they are. But (there is always a but).
Both encourage bad programming practices. Read this very extensive article about PHP and why it's such a fractal of bad design. The author might be biased against PHP, but many of the arguments they provide are very valid. Some of them might not apply today (the article is 3 years old and the language has evolved since then). Do I hate PHP? No, I don't. Maybe the most annoying for me issue with it is the deployment. Take for example the former web projects that I talk about previously. They both did not work with error_reporting set to E_ALL without spitting warnings and notices that mess the HTML page. Or maybe, would they work if I set the memory_limit too low because I have a server with just 256 or 384MB RAM and I must set the memory_limit low just not to overload the web server in case of a high peak of incoming connections. Or maybe some functions or modules are disabled in my production deployment of PHP, but this application requires some to be enabled, so I must always have a superset of each feature/extension/module enabled just for all deployed web applications to work.
Still, I like PHP, it gets the job done, it's quick (version 7 is rumored to be much quicker that the current versions) and with the help of modern PHP frameworks, the end result is of high quality.
But, the same trouble exists with MySQL. While I tested the second application, although I clicked on a insert button inside a form to insert a new record in the database, the record would not get saved. I couldn't understand why, not until I run the INSERT query myself using a MySQL client (HeidiSQL in my case, a very lightweight and neat client). The server responded that "column X does not have a default value and is not nullable". Ok, I think, this is correct, since no value is provided for this column in the statement. But why does this code work in the initial developer's production server? I found the truth when I comment out the sql_mode variable in my.ini and restarted the server (so that the server used the default options). I re-run the same query and it worked. Though one would ask at this point: what did MySQL insert into the column that is not nullable and does not have any default value? The answer is 0. Yes, 0. If you consider this a valid SQL standards behavior, then I give up. A HUGE issue with MySQL's bad design. The server behaves differently when running SQL queries just because a damn parameter has different values between two deployments. Yes, this is standard SQL behavior (NOT). This sucks and made me hate MySQL (or any forks I say again). It's bad design, don't use it. I've written about this in the past, maybe you want to read my previous article. Want to see another example? Take the same SQL statement and execute it in PostgreSQL 7, 8, 9 and it will work the same without altering any damn configuration variable, no matter what.
Ok, that's it. I just had to write about what was circulating in my mind during my involvement with these two projects. I do not blame the developers of these projects, they had the best of intentions, using the technologies they were taught. I could provide them some insights about how to improve their projects's code just to be more maintenable by a third party, but in the end, it will be their personal effort in this direction.
Feel free to share your thoughts on my post. Thank you for reading this lengthy post.
