Is there more bad PHP than bad Java?

By Confusion on Sunday 8 February 2009 11:34 - Comments (7)
Categories: Java, Software engineering, Views: 4.316

Bad code is code that invites future bugs due to being incomprehensible or fragile. Although this is mostly the result of a lack of forethought and design, I think that in some programming languages it is much easier to write such code than in others.

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.

As a result, I think it requires more skill and thought to write good code in languages like PHP and Javascript then it does in a statically typed, 'restricted', language like Java. However, these are precisely the languages that less skilled programmers use more often, because they seem simpler. Consequently, there is necessarily more bad PHP than there is bad Java.

Volgende: Behulpzaam of bemoeizuchtig? 02-'09 Behulpzaam of bemoeizuchtig?
Volgende: Ultrashort JAXB tutorial 02-'09 Ultrashort JAXB tutorial

Comments


By Tweakers user RobIII, Sunday 8 February 2009 14:27

I don't agree with everything. Just about every language allows oneself to shoot them in any bodypart when used incorrectly. Though I won't try to hide my dismay of PHP I think a lot of code out there, "visible to the naked eye" and thus published on the web, is rubbish PHP code and a lot less Java code. I have no exact figures, nor do I care, but my gut feel is that, "behind the curtains", there might be more Java than PHP. At least in a broader spectrum than web applications. All I know is that I have seen a lot of bad, bad, Java code (see TDWTF you referenced yourself) which had nothing to do with namespaces, dynamic typing or functional programming properties of the language but with bad algorithms, basic 'off-by-one' mistakes, over-engineered classes and 'spaghetti code' all around.

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

By Bram, Sunday 8 February 2009 14:31

Although I largely agree, dynamic typing does not have to be a 'bad thing' by definition - it all depends on how it is implemented in the language and used by the developer.

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.

By Tweakers user crisp, Sunday 8 February 2009 15:17

Developers losing their discipline (and often also interest) half-way in a project is, in my opinion, a bigger threat to unmaintainable code.
And 'managers' pushing for impossible deadlines ;)

By Tweakers user EvilWhiteDragon, Sunday 8 February 2009 16:54

@crisp:
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.

By Tweakers user RobIII, Sunday 8 February 2009 17:48

And 'managers' pushing for impossible deadlines ;)
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.

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.

By Tweakers user Confusion, Sunday 8 February 2009 21:04

@RobIII:

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.

By Tweakers user dragonspirit, Monday 9 February 2009 11:04

Deadlines are a pain in the neck. They are almost never accurate, they are almost always impossible to hold and not to mention, they create pressure and stress which can cause even further delays imho.

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