Is there more bad PHP than bad Java?
I think there are three main reasons why a language may be more bad-code-prone than others: lacking namespaces, using dynamic typing and providing functional programming possibilities. Now I am not argueing that it is an inherent feature of such languages that they result in bad code. Rather, I think that these languages provide more, and easier, ways to shoot oneself in the foot. Dynamic typing and functional programming provide easy ways to circumvent the restrictions imposed by a proper design, while the lack of proper namespaces does not allow you to implement a proper design at all.
What makes a program, and it's underlying code, 'better' is usually just the discipline of the developer(s); the thrive for maintainable code and the need for a deeper understanding of what the creator of the code is trying to do. I see all to often developers that just don't care how their problem gets solved. All they care about is that their problem does get solved. Most projects start off in either of 2 directions: the "let's code first, solve problems later" direction or the "let's design first, code later" direction. We all know the latter is the way to go and the first isn't even to be taken seriously into account. But more often than not I see projects gliding more and more in the first direction the more and more a deadline is in sight or the more time has passed. Developers losing their discipline (and often also interest) half-way in a project is, in my opinion, a bigger threat to unmaintainable code.
Of course there are always the 'bad apples'; the 'developers' that should actually be shoveling manure or the 'developers' that used to be 'all that' back in the eighties but failed to keep up with technology. And the 'developers' that aren't 'developers' yet, because they're still learning the basics, but get assigned to a project anyway. These 'apples' are the other main cause of unmaintainable code.
True; some languages make it easier to take the 'dirty' route and some languages encourage it a little too much. But PHP, Java, Visual Basic, C and it's derivatives, Delphi and many or most other languages have had their critiques in their time and no language is perfect. Development is a craft. As a developer you are a craftsman. If you can't handle your tools (hammer, programming language) as it was intended you will end up with a steaming pile of crap (a table that falls apart when you put a glass on it or an application that crashes whenever a user enters an invalid date).
It's easy to blame a language and, again, though I personally have a hate-hate relationship with PHP I do think that even PHP allows for neat, structured, organised, coherent and tidy code.
On a side note:
What I never understood is PHP.net allowing comments directly below the documentation. Documentation should be to-the-point, strict and correct. A lot of beginners can't make heads or tails of the information and end up copy/pasting the rubbish from the comments below. I do think it's nice that people can add extra information to the documentation but it should at least be 'screened' or otherwise 'cleaned up' before it is published; and even more so when that information is an integral part of the documentation. The worst rubbish in code I usually find in php.net's 'documentation'.
If you use the power of dynamic typing as it is available in languages such as ObjectiveC, and follow the 'best practices' and patterns, you have a great extra set of possibilities as opposed to only using static typing.
And 'managers' pushing for impossible deadlinesDevelopers losing their discipline (and often also interest) half-way in a project is, in my opinion, a bigger threat to unmaintainable code.
One teacher once told me that more than 50% of coding projects go over the deadline. While that may be true, I had to ask the following question: If more than 50% of the projects go over the deadline, then the person that sets the deadline must be wrong.
Then the teacher disagreed, because as stated above, even if a programmer starts with thinking first, coding later, most developers fall back to coding first, think later when a deadline gets too close.
So, one should conclude that (tight) deadlines are causing projects to become unmaintanable. That causes yet again more pressure on the deadline...
Thus, probably the deadlines are too tight to start with, and developers stop thinking straight because of that.
True, but that's just the tip of the iceberg. Managers pushing for impossible deadlines have been around since the dawn of day; sales contributes to that by promising customers the impossible, marketing blabbing about things that can't actually be done but now have to because of them and add to that 'incompetent' project managers that believe developers on their word instead of having an actual insight of the process when calculating the required time and the result is that deadlines are usually just bogus markers in time that mean nothing other than a point that can be moved around freely.And 'managers' pushing for impossible deadlines
Most IT projects (I don't have the numbers but my gut feel is that 50% is a very optimistic estimate) tend to exceed deadlines. We see it all the time and have gotten so used to it that the "deadline" is usually no more than "that awkward meeting explaining why the deadline was missed".
True; there's always the risk of misjudging the required time for creating a project but any well established developer should be able to tell you to take these kind of 'corrections' into account. And then add some extra. And some more. And then double the time you think you need. And, according to the type of developmentprocess, even double that again to get an estimate close to something realistic. Most developers, myself included, are usually too optimistic when estimating required time for developing X or Y. We forget to take into account the time that you need figuring out why something doesn't work as expected, getting the required specs to get started in the first place, or struggling with external parties to get some required documentation or ... you name it. No, or very few, projects go as planned down the line; something always comes up. And these are the things people forget to take into account.
And then there's the customer that won't pay because the deadline was exceeded and actually caused it theirselves by changing their minds 15 times a week during the project... and though these kind of things can be put in writing to ensure these kinds of thing don't happen, they (almost) always do anyway.
I was specifically interested in the difference in the amount of bad PHP and bad Java code. I agree that most bad code is the result of a lack of forethought and design, both upfront and while coding, but that holds for every language, so I glossed over that in the first paragraph, as it cannot explain such a difference.
Now this difference may indeed a matter of visibility and in that case there is also a lot of bad Java / C# out there. That leaves the question whether a language like PHP encourages bad programming more than Java. A carpenter that finds himself with a toolkit that lacks a hammer, but does contain a crowbar, may find himself hammering with the crowbar.
It's almost always true that us developers have to give a time estimate before a project gets started, but one thing that will always remain hard to explain to a superior is that is exactly what it is called...an estimate.
If I get told I need to create a website with complete administration for users, products, calendar items etc. How on earth can I be expected to give an accurate prediction on time involved. The problem almost always comes from the unexpected. Simple things that create delays noone ever seems to think of: A simple phonecall that will get your mind away from your project. Doesn't have to be a long call either, one minute will do. You get distracted and need to focus on the call, therefor loosing the focus you had on the project and it takes to get back into it.
I'm not sure about the differences in bad coding between PHP and Java, but I do think that open source is both a great thing, and a living hell. At work I program ASP.NET using VB.NET or C# depending on the requirements. I won't say that's much better though.
Personally I'd say the bad coding is not a matter of the language, although for some languages you just can't help but need to use workarounds to get to where you wanted to go, that in itsself can create bad code.
Comments are closed