Develop robust code in PHP, part 1th

Developing robust Code series in PHP is about solving real-world problems with large and medium applications. This series of articles focuses on the new features available in PHP4, focusing on a number of tips and tricks that make development work easier. In this series of articles, you will find many examples and techniques to learn, along with a large sample of code. In this first article, PHP master Amol Hatwar from a higher perspective on how to design and write error-free, maintainable code for medium to large Web applications.

If you are a developer of a Web application and need speed, functionality, and platform Independence (platform-independence), then PHP will work for you. and PHP is free, easy to learn and deploy. These are the biggest benefits of making PHP so popular. But these advantages can also become drawbacks. Because PHP is easy to use, developers will often first shove code into the editor when they should be planning and designing. Also, in PHP, there are more than one way to solve a problem, and it is easier to make that painful mistake, which is difficult to correct later.

In this series of articles, you will learn how to avoid many errors. Don't be surprised if you stick to the bottom of the line and you find yourself trying one or two times to write code without errors. I'll also point out the new features available in PHP4 that make development work easier. Most of the examples I want to introduce are used to handle practical issues such as scripting Configuration and installation, file processing, and database usage. Even if you are unfamiliar with all this, you will find it easy to understand. However, I assume you have a rudimentary understanding of PHP. If you need to review, you'll find that the resources listed at the end of this article will help you.

Lay a strong foundation

Writing code in PHP is very similar to writing code in a language like C. Because they are syntactically similar, they can cause similar code maintenance problems. When you have to develop large applications, you may want to write a lot of code. As time passes, the code can become unmanageable, and errors will quickly take over. No matter where you hear that statement, don't believe it-at least not all. However, the more important fact is that if you find yourself maintaining code too frequently, your application's design may be bad first.

Design code correctly

The choices you make initially affect the degree of freedom you will have when you write your code later. This makes the right design an important prerequisite. Although design can be an extra ritual when you solve a trivial problem, you must at least know that this is the way to do it. Many people think of design and planning as extra overhead. But with bad design or no design at all, the result is always sloppy code. Keep in mind that clever coding does not make up for bad design. Although how to design an application is beyond the scope of this series, I'm going to tip some questions that should be kept in mind when designing Web applications.

Division and Conquest

It is always preferable to design and write large applications with smaller, loosely coupled parts. In this way, each part is maintainable. For example, a Content management system (Management SYSTEM,CMS) may be distributed across a number of smaller modules such as user authentication, display, content resolution, and viewing statistics. And, if your module is generic enough, you can reuse code in other applications that you develop. Programmers often do this, but they still complain. The trick to coding is to have each module have the functionality it absolutely needs and that's it. Give a module a lot of functionality, just right.

Never consider in the page

If you're interested in using PHP to make your HTML pages more dynamic, this part will work for you. When you want to display the date and time on each page to make it appear to be up-to-date, this is usually the beginning of the habit. Each HTML page becomes a small php script with a limited number of lines, and the date function is hidden somewhere. If this is what you want, you must accept that this is the easiest way to make the job work. But imagine what changes you have to make to change the format of the date rendered on the page. You will have to change the code within each page.

Obviously, there is a better way to achieve this goal. My favorite way is to use a configuration file and define a constant in the configuration file that retains the format string of the date () function. You can then use the date () function where you want it. Each page still ends with a script, but you want to completely minimize where you have to make changes to a single line of code.

Figure 1. Avoid hard coding

As shown in Figure 1, you can see the date format changes on all pages. The idea here is to avoid duplicating code and hard coding. Keep this in mind when writing large applications. When you avoid copying code, debugging and maintenance becomes easier.