ASPit - Totally ASP JSit - Totally JavaScript
Search PHPit

Use this textbox to search for articles on PHPit. Seperate keywords with a space.

Advertisements

5 Tips To Speed Up PHP Development

(Page 2 out of 2)

Tip #4 - KISS (Keep It Simple Stupid)

During the development of a new script, you will probably run across many problems, and you'll have to think of a good solution. The best way is to keep the solution as simple as possible, and as soon as you notice that your code becomes 'filthy', you should consider re-doing it in another way. By filthy I mean overly complicated, and believe me, I've written plenty of filthy code myself. You get started on some solution, but along the way, you discover more problems, and instead of taking a step back and looking at what the actual problem is, you furiously code along. This might seem to save time, but in the long run you will only end up with thorny code, that is hard to understand.

The best way is to make everything as simple as possible. I keep everything as short as possible, and my if-statements and loops are never longer than 10-20 lines. If they become longer, I will first look if I can't do it simpler, and if that's not possible, I break it up in blocks, to make it easier to follow. In some cases I rewrite a particular block of code 3 or 4 times. This might seem a huge waste of time, but it will save you a huge amount of time in the long run.

So in short, try to keep everything as simple as possible. You should be able to immediately understand what's happening, without having to read a huge API guide or the comments.

Tip #5 - Document your code

Another great way to speed up development is to properly document your code, especially the complicated parts. However, you shouldn't over do it. The style of comments below is ridiculous, and completely pointless:

// Opening connection
$linkid = mysql_connect ('localhost', 'sa', 'pass');

// Selecting database
mysql_select_db('mydb', $linkid);

// Running a query
$query = mysql_query ("SELECT * FROM bla");

// etc...

?>

As you can see, the comments add no value at all. Just by quickly glancing, you can figure it everything the comments say, so the comments don't serve any purpose at all. Better would be something like this:

// Get our content from database
$linkid = mysql_connect ('localhost', 'sa', 'pass');
mysql_select_db('mydb', $linkid);
$query = mysql_query ("SELECT * FROM bla");

// Below is the code for our search algorithm
// This algorithm first looks for a certain keyword
// and the orders it on relevancy

// ... code for algorithm goes here ...

// Now we must make sure that all the posts
// are filtered through the sensor.
// This sensor checks each post, and looks for bad stuff (tm)

// ... code for sensor check ...

?>

This is already much better, because we immediately know what the purpose is a of certain code block. From there we can then figure out how the code actually works.

Even this style of commenting isn't perfect, but there isn't a "perfect" style of commenting. Each developer has his or her own style, but make sure that other developers can read your code as well. This is especially important when you work in a team.

If you properly document your code, you will be able to understand it much easier later on, which means you won't have to spend (much) time on figuring out what the code actually does, and can immediately start writing new code. Good documentation can really save you a good deal of time.

Conclusion

In this article I have shown you five ways to shorten your development time and being able to release faster. I must tell though you that the above tips don't always work, but even if you only use one or two shortcuts, you've already saved precious time.

If you have any tips yourself, or would like to comment on one of the tips above, feel free to leave your comments below.

« Previous: Tips #1 - #3



15 Responses to “5 Tips To Speed Up PHP Development”

  1. Millisami Says:

    I’ve gone through many articles to find and understand good PHPFramework.
    I did find many articles and frameworks.
    But this article helped me a lot not in the sense of the ‘Speed Up PHP Development’ but in the sense of good framework like Seagull, CakePHP.

    Thanks a lot.
    Regards
    Millisami

  2. Harinder Says:

    HI,

    The advices you have written are very good and practical. The soutions you have given can really save developers time.

    Thanks

    Harinder

  3. Ryan Says:

    Another good PHP editor, (sorry linux only), is Quanta Plus…I use it all the time. Code completion, syntax highlighting, project based, etc….and its free

  4. Rod Says:

    I use EnginSite PHP Editor/IDE from Luckasoft. It’s excellent!

    http://enginsite.com/php-editor.htm

  5. Ben Says:

    And another good PHP editor ive found is one called PHP designer 2005. Occasionally a little buggy, but free and one thing i like is that you can set it to type the close of brackets when you open them, and puts the cursor in between. Also has a syntax checker if you download the php intepretor

  6. Daniel Says:

    I too use PHP Designer 2005. It is very handy, especially when you download the interpretor (http://www.php.net/downloads.php). The interface shows the includes and classes in a tree so you can see the layout. Also has the code coloring for HTML, CSS, XML, PERL, JS, VB, C# and even SQLs. As stated in the beginning of this article, I used to be one of the ‘notepadders’. :) I must admit though… Not having to count lines to find an error (with wordwrap turned off) is worth a lot to me!! Great article, Thanks much!

  7. Spajus Says:

    There’s no alternative for speeding up things to Zend Studio. Code coloring is a must for even a text viewer nowadays. And you should use PHPDOC type of comments, not //some thing ones…

  8. Dennis Pallett Says:

    I don’t really like PHPDoc type of comments myself. I find them really annoying, and it really clutters up my PHP files. I’d rather have the documentation seperate.

  9. Matt Kaufman Says:

    I have a license that I bought for Zend IDE, and I actually prefer (and use) jEdit over it .. it’s far faster and has a great set of plugins that can be added in very easily: http://jedit.org

  10. Luk Says:

    For me the best editor is Notepad++

  11. SN Says:

    I have been using a framework not mentioned in the tips called Zoop Framework for PHP. It has really helped me productivity wise. Thanks for your tips. Additionally I have been using Quanta myself as an Editor. It doesn’t have a windows port, but runs great on linux and macOSX, is free, and has an Intellisense like feature.

  12. Kevin Says:

    I would have to disagree with the part that says: Don’t re-invent the wheel. This is a very limited way to tell php programmers, as being lazy and not promoting development. Yes you can customize those scripts, but why do that when you have to ability to code your own. Who cares if it takes a little while, atleast it can be a very good learning tool. But I do have to say people new to php could use one of those, but don’t discourage ones who are able to code their own CMS, or whatever.

  13. makro Says:

    I partially agree with the author BUT i have to say, that many Frameworks as well as Scripts have various downsides, which could well slow down the development process in the long run:

    1.) Licenses: What to do if you used a script / framework under GPL (free) and want to go commercial?
    - You have to publish all of your code, what in turn makes the whole application vulnerabe, because everyone can see your source.

    2.) Functions: What if you depend on a framework and some day need to implement functionality, which the framework does not provide.

    - You have to rewrite the app or extend the framework itself. All your changes are like to be lost after a applying a Framework (sourcecode) update.

    3.) Modules: So you use modules for your framework to speed up development, huh?

    - Many bad things can happen to your app: Sourcecode of every module you use is public (vulnerable).
    - Licenses can change, can be tricky or expensive.
    - Updates of the framework can break the module.
    ….

    There are many other concerns on this topic but they would be out of scope of this posting.

    For my work as freelance programmer and systems professional i always “reinvented” the wheel and this is what i got:

    Thin, fast, reliable, “personal” and secure Applications or Daemons.
    No other solution than the tailored one can really do what you (or the customer) want to do it.
    Frameworks and CMS are often slow, unsecure and offer all-singing-all-dancing stuff, you really will (probably) not need.

    I always said: Quality overrules Quantity.

    If more Programmers and Companies would get the point of this statement, there wouldnt be so much, really much, crap pieces of software out there.
    Additionally, speeding the development process (which includes analysis and design AND testing / debugging) has negative effects on the income of the developer and the financial expectations of your customers. This is where relationships between development, open source, closed source, marketing and so on come into view and covering these here would be FAR BEYOND the scope of the article and this posting.

    It always is hard for the worker when the market exploits his industry.

    Greetz,
    makro

  14. WC Says:

    1) Publishing your source code does -not- make it more vulnerable. Bad coding does. Publishing bad code only makes it easier to find the loopholes.

    2) Extending a framework is easier than writing the whole thing from scratch.

    3) Licenses can’t change on the current version of a module. Future revisions, yes, but not the current one. Update of -anything- can break your code. That’s life. It’s still a -lot- faster to fix the new problem than write everything from scratch.

    The programming market is changing. Speed of code is not nearly as important as it used to be, and speed of creating code is much more important.

    There will always be jobs for ‘reinvent’ people, but the current market trend is towards ‘reuse’ people.

  15. Steve Says:

    Frameworks are good. But make sure you select one that you are comfortable with. Don’t just follow the pack.

Leave a Reply

About the author
Dennis Pallett is the main contributor to PHPit. He owns several websites, including ASPit and Chill2Music. He is currently still studying.
Article Index
  1. Tips #1 - #3
  2. Tips #4 and #5
Bookmark Article
Download Article
PDF
Download this article as a PDF file