10 signs of crappy PHP software

  • Nightslyr
  • Proficient
  • Proficient
  • Nightslyr
  • Posts: 283

Post 3+ Months Ago

A blog article describing ten common signs of crappy PHP software. Some are straight forward (reinventing the wheel, needlessly playing with the error level). Others are sure to be the cause of controversy (using globals).

http://www.phpfreaks.com/blog/10-signs-of-crappy-php-software
  • Anonymous
  • Bot
  • No Avatar
  • Posts: ?
  • Loc: Ozzuland
  • Status: Online

Post 3+ Months Ago

  • joebert
  • Fart Bubbles
  • Genius
  • User avatar
  • Posts: 13502
  • Loc: Florida

Post 3+ Months Ago

The irony of mentioning reinvention of the wheel within an article that itself reinvents the wheel is my highpoint of the day.
  • UPSGuy
  • Lurker ಠ_ಠ
  • Web Master
  • User avatar
  • Posts: 2733
  • Loc: Nashville, TN

Post 3+ Months Ago

lol, I suppose there is a bit of irony in it, but I was hoping to see a good round-about over one of the controversial topics. Now I've got to go find Rabid Dog and tell him you said bad things about him to be entertained. :lol:
  • joebert
  • Fart Bubbles
  • Genius
  • User avatar
  • Posts: 13502
  • Loc: Florida

Post 3+ Months Ago

Then there's #6, the author is already second guessing their confidence in the article halfway through.

Quote:
(ok, maybe not my life, but if you find a proper use of more than 2 levels of inheritance, I'll buy you a beer)
  • devilwood
  • Silver Member
  • Silver Member
  • User avatar
  • Posts: 436

Post 3+ Months Ago

Sounded like a couple were just naming schemes. While good names can make code easier I don't think it infers that it's crappy. For programs I know others will be using I try to keep it clean and good descriptive variable and folder names. If I'm writing code that I don't want others to use then I may do it with klingon variable names just to make it difficult for anyone trying to use the code. It's not foolproof, but they'll atleast have to work at it to figure out what's what, but it doesn't mean my klingon code is any more or less 'crappy'.

I think the globals is the controversy, but it still goes into how your program is deployed. There's instances where globals can be used. I'd say writing a program is like writing a speech. Rule#1 know your audience. A crappy program is one that just doesn't work for it's targeted audience/users.
  • spork
  • Brewmaster
  • Silver Member
  • User avatar
  • Posts: 6250
  • Loc: Seattle, WA

Post 3+ Months Ago

The article is complete rubbish. The author just dug up a bunch of common poor practices (most of which apply to all programming, not just PHP), made them language-specific (or at least tried to), and tried to pass it off as original. He clearly has no concept of software architecture, design patterns, or the DRY principle.
  • Rabid Dog
  • Web Master
  • Web Master
  • User avatar
  • Posts: 3245
  • Loc: South Africa

Post 3+ Months Ago

Said bad things about me?

I personally think reinventing the wheel is fine. How else do you learn? Imagine Linus had taken that stance and merely enhanced another OS? LOL ok bad example but you know what I mean :)

Ok here is my 2 cents

He has a point at point 1. If I found a class called object I would laugh :)

Point 2. I don't like globals either rather define constants ( yes I know they are different, but a global variable that changes can quiet easily be encapsulated)

Point 3. I agree with

Point 4. I agree with kinda, people often define classes as function libraries. There are times for this and then there are times not for it.

Point 5. I kind agree with but there are times when you need it

Point 6. There very well may be a need for large inheritance scheme. I haven't found one but there might be. I steer clear of inheritance all together.

Point 7. Trying to look smart

Point 8. Error levels should probably be controlled in a central point, so I agree

Point 9. How is defining a core a bad idea? should we rather name it engine?

Point 10. Ok you have grannies cooking site that has 6 pages. go download smarty and implement it for those pages LOL Here I whole heartedly disagree.

In closing:

PHP is not an object orientated language. It just tries to cater for those that are used to OO. PHP is a scripting language and any extensions or ehancements done on a system built in it are going to be a nightmare. It is weakly typed, doesn't need to be compiled before being deployed and should not be used on an enterprise scale application. Discipline is required when working with PHP and I am afraid to say that we all suffer from the "get it working" syndrome when deadlines approach.

I would say that the simplest way to build a system that allows for further extensions is to use a rigidly defined service layer with pre and post conditions (Exceptions) that people can make use of to extend the system. This way this way the developer calling CustomerManager->createCustomer($customerRequest) doesn't need to know anything that is happening under the hood.

So in short, anyone that writes an article like this needs his head read. It can be the best written PHP program on the face of the planet and I still will not touch it with a barge poll. There is a reason it is written in PHP. Java is free and far more mature than PHP so why wasn't it done in that? I tell you why, because some manager read that PHP is free and people love it so decided to get a guy out of high school that knows PHP at half the rate of a professional developer (who would have told him he is on drugs for even considering it) did a technical specification with no technical experience and walked away!

Sjoo I feel better I got that out :)
  • Nightslyr
  • Proficient
  • Proficient
  • Nightslyr
  • Posts: 283

Post 3+ Months Ago

To be fair, since I've talked to the guy who wrote the blog post a few times, with point 10 he's not suggesting that one should use something like Smarty all the time. In fact, he's not high on using a template engine at all. He tends to use straight PHP for output.

But, yeah, he didn't articulate that well.

Also, keep in mind that the post was written on a site that caters to people of all skill levels. While the vast majority of his points fall both in the "no duh" and "common, language agnostic mistakes" categories, it's safe to say that a lot of the people reading it wouldn't know that. My own experience on their forums trying to help some of the other members is all the proof I need of that. Of course, that begs the question of why is he talking about things that would be above their skill level (design patterns, and whatnot)....

Finally, regarding point 4, simply storing a bunch of functions in a class to create a library is pretty pointless, and not really what OOP is about. In PHP specifically, there's no reason to do that when you can simply include/require external files from anywhere.

EDIT: Regarding a folder named 'core':

He, again, didn't articulate his opinion well. He clarifies (slightly) in the comments section:

Quote:
No. What that point says, is that developers often define a core directory as an excuse to group unrelated code and justify use of that code throughout the application. The bigger the "core", the more code will be interwoven with the application. Your ZF "application" directory is not the "core" of your application. It contains different parts of your application, which are dependent on different parts of the library. Hardly the same.


and:

Quote:
It warns that possibly the authors have created unnecessary dependencies on what's in this directory. Finding such a directory does not make that given fact, but in my experience there is definitely a good chance.


Just trying to keep the discussion flowing/balanced, as I think the comments below the blog post are more interesting than the post itself.
  • Rabid Dog
  • Web Master
  • Web Master
  • User avatar
  • Posts: 3245
  • Loc: South Africa

Post 3+ Months Ago

Yeah I read through all that but it kinda makes me conclude that one of two things happened here

1) He didn't put enough effort into completing the article correctly (I read all the points of it not being a tutorial and disagree, if you are going to make statements like that then rather put it on your blog)
2) He ran out of time and started snipping content.

Once again I point out that PHP is not an OO language, so most of his arguments are invalid on those grounds. You cannot declare something static and if you can you can still invoke it in the context of an instatiated object (MyObject::staticFunction() $myObject->staticFunction()). So the language is open to abuse and really as I pointed out, I would not touch any system based on PHP unless I started and finished the system. Had many offers to do it, never accepted one.
  • 448191
  • Born
  • Born
  • 448191
  • Posts: 1

Post 3+ Months Ago

Heh. The Internet really is a small place.

My apologies for bumping my thread, but as the author of that blog post I have a couple of things I'd like to share.

"The irony of mentioning reinvention of the wheel within an article that itself reinvents the wheel is my highpoint of the day."

Obviously I am oblivious to any irony in this. The post was created originally as a quick and easy way to decide whether or not a PHP application is one that would cause you headaches. It doesn't try try to be original or "invent" anything.

"Then there's #6, the author is already second guessing their confidence in the article halfway through."

What people (here and on PHPFreaks) seem to conveniently ignore is that these aren't "hard rules" or whatever you want to call it. In fact, Zend Framework triggers a couple of these warnings in some degree, but I certainly wouldn't label it a "crappy" framework (Zend_Db_Table maybe, but Table/Row Data Gateway just sucks). Overall, that comment was just meant as nuance.

"The article is complete rubbish. The author just dug up a bunch of common poor practices (most of which apply to all programming, not just PHP), made them language-specific (or at least tried to), and tried to pass it off as original. He clearly has no concept of software architecture, design patterns, or the DRY principle."

I assure you I have. In fact I wrote a tutorial touching on these subjects for PHPFreaks. I am aware of the SRP, DRY, LSP, OCP, other principles and practices, and I can pretty much dream the GoF book and PoEAA. It's kind of convenient to label someone as ignorant without looking a little further to see if there's any truth to your assumption. Keep your ego in check.

"Point 7. Trying to look smart"

Not really. Writing this post was prompted by my experience with a CMS called "SilverStripe". Do a quick search in the code and docs, look for a method called "singleton()" and a thing called "decorators". You'll see that this is a little more than just looking interesting, it is based on personal experience.

"To be fair, since I've talked to the guy who wrote the blog post a few times"

Yeah, I recognize your username.

"Also, keep in mind that the post was written on a site that caters to people of all skill levels. While the vast majority of his points fall both in the "no duh" and "common, language agnostic mistakes" categories, it's safe to say that a lot of the people reading it wouldn't know that. My own experience on their forums trying to help some of the other members is all the proof I need of that. Of course, that begs the question of why is he talking about things that would be above their skill level (design patterns, and whatnot)...."

I have been trying to lift to the general level of OO knowledge on PHPFreaks. So far with only limited success unfortunately.

"1) He didn't put enough effort into completing the article correctly "

Not enough effort? Probably. To be completely honest I had naively expected a little more acceptance a little more "hey that's worth looking into" rather than the "wtf this guy is tripping" attitudes.

"(I read all the points of it not being a tutorial and disagree, if you are going to make statements like that then rather put it on your blog)"

Well it "was" a blog post, and not a tutorial. In hindsight, considering the audience, I should have included a little more explanation and references.

People actually read PHPFreaks post, imagine that...
  • Rabid Dog
  • Web Master
  • Web Master
  • User avatar
  • Posts: 3245
  • Loc: South Africa

Post 3+ Months Ago

Well I never, nice to meet you :)

First up I would like to thank you for taking the time to sign up and engage us :)

Second up, I would like to point out as well that while your points do have merit I am incline to accept them as a P.O.V. Fortunately I will never be in the position to extend or maintain any PHP application as I would never consider using PHP for ANY business system :) It is handy for odd jobs and was a really cool learning curve but that being said (and as you pointed out) it gets abused way to often and people think that because they can execute a for loop they are now programmers.

I appreciate the point of trying to lift OO knowledge and I back that 100%, but as I found out and I am sure you have as well, people are not really willing to change the way they do things, the attitude to a large degree seems to be "it has worked for 100 years my way and that is the way I am going to carry on doing it and if you don't like it then bug off". Also people get very sensitive if they see someone slating their ideas. Prehaps slating is to harsh a word but you know what I mean. For example, a solution I proposed (and was finally accepted) was using request and response objects.

The primary disagreement was based on the fact that people are used to passing a number of parameters into a method and returning an object as the response. Mine was based on an object of type request and a response of type response. To get people to try and accept this scenarion took a lot of convincing! Then also people were worried about performance passing objects as requests as opposed to primitive types. The conclusion I finally brought them to was to sacrifice a bit of performance for a large gain in scalability.

Ok the point of all that was to state this:
I understand were you coming from, even though I disagree with a few aspects and appreciate you putting it out there like you did. I think that as you pointed out it was a bit "naive" to expect acceptance as there are a million ways to skin a cat but my way is the right way :)

Your further comments on the issues raised by commentators were very interesting and I would enjoy a purely architecture discussion with you. I always love having my opinions challenged as it does one of two things. Solidifies in my mind that the solution is correct for the context or illustrates that the solution was way off and I need to rethink it. Either way I am winning :)

Your point on "keep your ego in check". Might I be so bold as suggest to rather keep the tone of replies as objective as possible? I know we all struggle with this but the one thing I hate about the internet and forums is how impersonal it is. When someone makes a statement we interperate the tone of their post based on our emotions at that time. We have no other grounds to judge you on asides from the post that you made and with what you have now informed us about can make a far more accurate judgement :) If someone told me I was talking rubbish I would ask them to validate the statement as they understood it. This way I can see if they know what they talking about and two understand their point of view better. I have always maintained that if you put it out there, expect it to get cut off :)

Finally, rigid definitions, I think your points were a bit vague in why they are bad and most of the comments made against the post were just due to a lack of understanding the context the statements were made in.

In closing, I would appreciate further dialog on past experiences with you and thank you once again for introducing yourself here. I think you could be a valuable member to have.
  • devilwood
  • Silver Member
  • Silver Member
  • User avatar
  • Posts: 436

Post 3+ Months Ago

Thanks for signing up. I enjoyed your post here that shed some light on some of the points our forum friends were making. I thought that was very cool you came across our discussion and could weigh in to give a completeness to the post topic.

While each of your topics were picked apart by the members here, I did understand the meaning of your tutorial and that was to provide some type of guideline to indentifying bad code quickly which I assume would be for like if I was asked to take a project and those points are some things I may look at in order to tell the client a re-write is in order or 'no I'm not touching your program'.

I've had really good experiences here and the majority of members are extremely respectful and helpful no matter of ones skill level. The layout is very clean, there's plenty of active members keeping new posts and competitions (I'm trying to plan a beach trip this weekend) , and a nice layout of forums from linux to flash. I sure hope you'll check back from time to time and join in other topics.

Post Information

  • Total Posts in this topic: 12 posts
  • Users browsing this forum: No registered users and 127 guests
  • You cannot post new topics in this forum
  • You cannot reply to topics in this forum
  • You cannot edit your posts in this forum
  • You cannot delete your posts in this forum
  • You cannot post attachments in this forum
 
 

© 1998-2014. Ozzu® is a registered trademark of Unmelted, LLC.