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.
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.
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.