Saturday, March 15th, 2008
Stay away from Bloated Class Methods, actually, bloated ANYTHING!
Why are there so many examples of bloated PHP methods out there?! I see a lot of bloated methods being used in examples through sites like phpclasses.org and a very large chunk of a project I’ve recently picked up which a few developers have worked on. Guys! remember! There is no good reason to bloat your methods to over 10-20 lines long and on the rare occasions that you do exceed 10 - 20 lines it would be more the exception to the rule as opposed to being the rule itself!
Let’s not forget what classes and its methods are supposed to be: Classes are blueprints for specialist components and their methods are singular actions which address one to a few (2 - 3 at most!) procedures at a time whether it be through the use of other classes or just through simple logic!
DO YOURSELF A FAVOUR! Write smaller specific class methods. I know it’s hard to get your head around. When I initially started doin’ it the right way, I thought that it was “fragmenting” the logic which seemed counter productive at the time, but with practice, you will find that encapsulating logic into small methods _AT THE RIGHT PLACES_ actually makes more sense than putting a whole chunk of logic in the one method.
Think about it - it’s the amateur spaghetti coder within you that’s trying to shove in all that logic into the one method - think back to when you first learnt how to program! Cramming all this logic into the one method is the same as the time you were doing with a single PHP page that grew to 2000 lines, a bloated function, an abused case statement or all that SQL you placed in the view layer and said that it was right because it’s convenient - It’s saying “I think we should do it this way because it’s easier… well for me it’s easier anyway…”
What will happen if you keep creating bloated methods is that as your code “grows” (into a monster), is that it will be harder and harder to maintain and test each unit of code because they’ve become so big!
“It’s not so hard, I know exactly where I put my code…” you say to me as you look over your shoulder tapping away at your giant method.
Let’s see you do that in 2 - 3 months time _after_ it’s released and we find some bugs or asking you to make a change. The number of changes then become an issue - instead of weeks or days you’re thinking months and semesters.
“You’re making too many changes! This is going to be hard to do. Well, not hard to do but time consuming.” You reason as you mess around with your search and replace and write a list for yourself on the whiteboard. How is it my fault that the crappy code you wrote is rigid and brittle?
Expect change and expect them occuring in random! Write code that is easy to follow and is straight forward. Documentation will not cover everything and it’s crazy to say that it does - I don’t want to spend time writing up sentences of instructions on how to use a method.
Writing smaller methods and semantically refactoring your bloated code (classes and methods) into neat semantic basic OOP principle following units is the key. nice encapsulation promotes readability and all that, but that’s for a discussion for another time.
To conclude, I’d like to issue a word of caution that’s somewhat unrelated to the post (I’ve said what I had to say), but brings up some recent memories - if someone argues that you should follow “convenience” over “convention”, you should get rid of them ASAP. They’ll corrupt your project’s codebase with their convenience code and come up with terrible ways of doing things.
Once they leave, you will have to deal with the mess they left behind and _that_ is a pain in the be-hind!
on Tuesday, March 18th, 2008 at 2:07 pm:
RV, if you want to give yourself a heart attack then look at the old code for SiteWorks Professional. There’s a function within the admin for generating the article multi-page editor. From memory it was close to 1000 lines long…
I had to edit it once and it took me over 1/2 a day just to make a tiny fix.
on Thursday, March 27th, 2008 at 9:03 am:
Had a look at it, it’s very bloated :) But as with everything, it’s not beyond repair. :)
on Thursday, March 27th, 2008 at 9:01 pm:
Hi rvdavid,
I am a PHP novice, but your article makes good sense to me. I have never written a script for scratch, however, I know enough to be dangerous! I have tinkered around with the code on my blog to modify for my own purposes. Great info, and I am looking forward to your next post! I just stumbled this one and gave you a great review!
on Thursday, March 27th, 2008 at 11:26 pm:
Hi John, I’m glad it makes sense to you! It’s aimed at novices and beginner level programmers.
Thank you for the feedback, I appreciate it. :)