21 errors of a PHP-programmer. Part III.
Description of seven last ‘fatal’ errors. These errors are conceptual on their nature and cause errors described in the 1st and 2nd part of the article. They also include such errors as insufficient attention paid to the project in whole and to the program code as its part.
One of the main advantages of PHP is its disadvantage at the same time: PHP is very easy to learn. This attracts many people but in spite of its false easiness it’s rather difficult to learn right and effective usage of this language.
As a rule we deal with insufficient programming praxis. Inexperienced programmers face the necessity of complicated web-applications creation. Thus the mistakes are frequently done which an experienced programmer could evade such as unjustified usage of printf() function or wrong usage of PHP semantics.
In this series including three articles the most typical from our point of view errors are presented. These errors may be classified on some categories from non-critic to the fatal ones. Together with these errors’ analysis the ways of their evading are described and also some little tricks which have been collected for many years of programming praxis are presented.
Audience of the article
This series of articles is meant for those PHP-programmers who want to evade the mostly common errors in the code writing. The reader is at least supposed to know general PHP syntax; some experience of practical language usage is also very desirable.
Introduction
One of the main advantages of PHP is its disadvantage at the same time: PHP is very easy to learn. This attracts many people but in spite of its false easiness it’s rather difficult to learn right and effective usage of this language.
As a rule we deal with insufficient programming praxis. Inexperienced programmers face the necessity of complicated web-applications creation. Thus the mistakes are frequently done which an experienced programmer could evade such as unjustified usage of printf() function or wrong usage of PHP semantics.
In this series including three articles the most typical from our point of view errors are presented. These errors may be classified on some categories from non-critic to the fatal ones. Together with these errors’ analysis the ways of their evading are described and also some little tricks which have been collected for many years of programming praxis are presented.
Part I: 7 ‘childish’ errors are described (21-15 backwards according to the grade of their importance in our classification). Such errors don’t cause serious problems but they reduce effect of program’s work and are also expressed in a bulky difficult to read code which is also difficult to change.
Part II: The next 7 error (14-8) which are classified as ‘serious’. They lead to the considerable reduction of code’s completion speed and scripts’ safety reduction; the code becomes even more complicated.
Part III: Description of the last seven ‘fatal’ errors. These errors are conceptual on their nature and cause errors described in the 1st and 2nd part of the article. They include such errors as insufficient attention paid to the project as a whole and to the program’s code as their part.
7. Programming by means of method ‘cut-paste’: wrong approach
Some beginners have a habit of copying another code, for example, scripts for addresses’ verification, mail sending and form processors. Such activities result into mixture of operators which does what it has to do although not in a proper way.
And if the code functions under optimal conditions, it will obligatory break down during real testing. At this holes patching never makes your code
- extensible: the program will look like a set of scraps which were fastened together. Ask an experienced programmer to change something in such script and he is sure to prefer writing one of his own. Unreadable code is an inextensible code.
- safe: you insert another person’s code into your project without knowing what exactly this code does. Think about it. And what if this code contains false system call which destroys all the files form your fixed disk? Besides that the same code cannot have the same protection and safety for different systems. And finally you’re simply copying someone else’s errors.
- fast: if you compose code from the parts of different scripts, you shouldn’t expect fast work from it. Thus in this case logical development of the script is simply absent; and it’s a common fact that script’s speed is based on its logic.
Before you copy code of someone else examine it carefully. Analyze what has been done and in what way. And only if this code is easy to read, fits into your program’s logic and doesn’t contain any errors, only in this case it can have pretensions of being copied. If these rules are observed, the copied part can be integrated into the project rapidly and smoothly.
Libraries are what you needUse libraries of PHP-functions only from reliable sources such as, for example, PEAR and PHP Classes Repository. Optional functionality which API from these libraries offers to you will benefit your project. So if you’ve found a ready-made library of functions which are necessary to you (from reliable source), its usage is always welcomed.
6. Absence of technical directives in the project
Once in the very beginning of my career I worked over one serious project (on PERL) in team with three other programmers. I was young (and I wasn’t a supervisor of a project), we had no technical directions. Each of us took his part of the project and worked over it on his own. When we started assembling our project our parts were quite different on their styles.
For example, one of my colleagues used BiCapitalization in the variables’ names. I used underscore ("_"). The supervisor of the project chose the most original style and mixed both methods according to his mood (this fact caused conflicts in the names’ space; everyone knows how unpleasant it is for a developer).
We needed 20 hours optional time; although nothing like that would have happened if we had set up clear technical directives for our project.
Technical directives describe structure and external presentation of the source of the project, determine methods and realization strategics of the final product.
For development of any project you have to set up technical directives and follow them. In the technical directives various working aspects should be determined: general items, for example, division of the source (its file structure) and more concrete ones, for example, rules of variables’ naming (suffixes and prefixes, global, in full).
Technical directives are the set of consent which should be observed independently from the personal preferences of programmers. Technical directives fix all the decisions concerning all questionable moments like these:
- which variables should be declared as global and how they will be differentiated from the local variables;
- structure of documents saving, i.e. rules in which directory this or that file should be placed: src or lib.;
- style and contents of comments;
- documentation rules;
- strings’ width.
Technical directives should be arranged into a document; each project’s participant should have its copy. After the project ends this document must be saved for the further addressings to the source.
Example of technical directives projectFor better understanding we’ll try to set a sample of technical directives: without details, the main items only. Of course, all the necessary elements will be presented but they will be rather schematically: in reality technical directives can easily have 10-40-pages length. It’s worth to mention that you don’t need to write new technical directives for each new project: it’s enough to have a ready-made sample and change it if necessary.
Technical directives for presentation of the project DesignMultimedia.comSo let’s give an example of the external presentation of the project. Having developed a document like this you may concentrate on the realization of the project only and don’t worry about incoherence of sources, naming conflicts or site’s structure if you develop your own site.
IntroductionThis part determines following moments:
- file structure
- documentation of sources
- comments: style, meanings, definitions
- directives concerning assembling of the project
- rules of variables’ naming
Explanations to the structure: <Here the explanations concerning all the described before rules and agreements are given in order to exclude every false interpretation> Each page of the initial text of the project contains following heading:
<Here the heading is indicated. It may include whatever you want: from the code’s sample to a simple copyright.> For example, all c. and h. files within PHP4 project had the following standard heading:
And the lower running title: <Here you place your standard lower running title; in the project PHP4 in all files .c and .h you can see following :>;
And comments if necessary. <Here explanations about the contents of upper and lower running titles are given; perhaps the reasons for their presence are explained (in depends on the running titles’ contents).>; Documentation In this part code’s documentation style in the application is defined: if it’ll be arranged in the javadoc form or XML Docbook Comments’ style Here the comments’ style together with explanation of abbreviations and some ‘phrases’ is described Rules of project’s assembling Here the rules in form of bans or directives are given, for example: ‘Don’t save different classes within one file’ or ‘Save each class within a single file’ Naming of variables Here you can write something like this : By naming of the variables in the given project the following rules are to be observed: [1] In the names of the classes bicapitalization is used. [2] Functions’ names are written with lower-case letters, for the separation of the words underscore ("_") is used. [3] Other more concrete rules. The idea to add this item visited me during the similar testing which I was asked to do by my friend. Having examined his code I was able to reduce the variables’ quantity on one third (that resulted into 400 per cent increase of data base addressing speed), quantity of strings in the program on about one half and beside that make many improvements with general result 1000 per cent speed increase (that means ten times faster). What is the moral? The moral is that quality, speed and safety of your code will incredibly increase in case you always have another available experienced programmer who will examine your code. Other person will pay attention to all the errors about which you even didn’t know and find simpler ways for solving this or that task. Beside that it’s easier for him to find such places of your code which make PHP work slower or which can be potential ‘holes’. One of the reasons for the incredible success of PHP project which is a language with uncovered sources is the fact that many people have seen the code. Thousands of people tested PHP for free against the presence of errors, potential fails, incompatibility, working speed etc. Thus by the appearance of a new PHP version minimum 2-3 very experienced programmers have looked through the code. As an ideal all the projects of medium/large scope should be looked through by at least two ‘guest’ programmers. As in any other kind of art a new look is always welcomed. But people are mostly satisfied with one tester. Person who is able to give rapid judgement about the work done and introduce constructive motions about the code’s contents and realization of a project as a whole is supposed to be an experienced expert. Often it’s useful to set up a short questionnaire for the person who looks through the code. Here are some possible questions: You may have written an application and had an idea that some moments are worth rewriting. To ‘patch up’ means to write patches instead of examining the reason of error’s appearance and its removal. If you’ve done such mistake and wrote patches your code won’t work properly which is caused by the compromise of speed and safety. Indexes for the project’s imperfections Of course, by the initial projecting of an application you suppose that your thoughts are the most correct ones. And you can understand that something goes wrong only in the last moment when the application (and its parts as well) is nearly written up to the end. There are two indexes which testify of a wrong project’s plan: This code is written well; it passes through the line in cycle and puts out the famous phrase of George Bush correctly. The syntax is correct as well as nesting. And nevertheless we could get the same result by the simple output of the whole string (print()). Improvement of program’s drawbacks When you realize that the program has some drawbacks or that it isn’t simply realized in the best way, you undertake proper steps for the code’s optimization. There can be plenty of variants this way: you can leave everything as it is, you may change some modules of the program or rewrite the whole project. In the most cases it can be useful to have a judgement of an independent expert: having looked through and examined the code he will be able to judge about scope of imperfections properly. Let’s examine three categories of errors: Ways of correction: in this case it’s necessary to document somehow the fact of error itself. When you decide to change or renew your application you’ll correct this error at once. As an example for the error of such class can serve wrong data organization in the separate part of application (simple massive in the place where it would be more logical to use an associative one; riding-crop instead of more suitable tree). Ways of correction: all you need is to change project of Windows’ dispatcher namely (not the whole operation system). It seems to be the mostly widespread case in the programming practice: single modules contain errors but the general project structure is correct. Ways of correction: if the application’s infrastructure itself was projected wrong, usually we need reorganization on the level of different program modules’ interaction. This is, of course, the most laborious work which takes a lot of time and it is rarely done especially if we speak about projects on the last stages of their realization. As an example of such errors we can demonstrate usage of simple files for saving the whole amount of information within such huge search system as Yahoo. Imagine such situation: you’ve got a task to develop a corporate application special for your company. You’ve spent hours on search and documentation of tone of documents, defined costs of the project, set up tasks and completed them. In three months you bring the ready-made project only to hear in response: ‘It isn’t what we wanted’. ‘Our demands changed’. ‘Yes but…’ ‘Eh, what program are you talking about?’ (Your initial customer is already fired from the company!!!!). Has something like that ever happened to you? A user is always to have the last word in the judgement about your application. It’s namely he who will use your application (and, of course, he will keep trying to use it wrong). Many programmers write such things which are masterpieces on their own but at the same time don’t correspond with users’ demands. And it often occurs because one or some ‘misunderstandings’. And these misunderstandings appear when you ignore the ultimate user during the development process. Don’t forget about your future users when creating an application. Always keep in your mind WHAT users want get from you and in what way the program should achieve the set aims. It’s principally important to have connection with users and pay your attention to following procedures: Permanent feedback Benjamin Franklin wrote in his ‘Poor Richard’s anthology’: ‘One stitch in time is worth of nine’. We can apply the same rule for the applications’ development. If you really want to finish your project as soon as possible, it’s very important to have connection with user and be interested in his opinion about your program. What do they like about it? What do they dislike? How can you improve your application? Creation of models Creation of the program models is a whole system which includes many tests and communication with users and acting during the whole period of application’s development. However doing tests on models takes much time. And it’s worth to start it from definition of users’ ‘testers’ group. Check application against conformity with demands but also pay your attention to the direct responses of users themselves. Besides that many programmers test an application only after having written and assembled it. They make a mistake cause this may fail the whole project: the differences between what a user needs and what you’ve done are too big. Besides that users often understand what they really need only having some real sample before their eyes. User’s demands to the project are constantly changing during the development (although many programmers would prefer quite the opposite). There is a method for evading this headache: divide the whole application development process into some stages. By ending of each stage think over the following: Usually good practice is considered such limitation of stages when some considerable portion of user’s interface is completed. As for me, I consider the first stage finished when the first variant of common application’s interface is ready. This occurs when designers define the backbone of the site. The next test of user’s interface can be done when the mostly general demonstrational model of functionality of your application will be ready. Then tests are done after the finishing each ‘module’ or ‘multiplier’. The example of such ‘module’ we may call users’ dispatcher in application or search system of a site. By testing I gather my own testers’ group (I invite others who are more competent in the subjects tested at the moment) and offer them the same questionnaire which I described before. This enables you to see ‘general’ result of your work on the given stage. You may ask additional questions or hold to the initial list. Beta-testing This is the mostly widespread testing form which looks a bit like modeling but usually beta-testing is done when the project is on the last stage of its development. The project is sent to a certain group of beta-users; they test an application and sent their references, comments and error messages to the developer. Beta-testing isn’t as interactive as modeling and it’s worth to do it as early as you can. However beta-testing is simply necessary before you release your application. Nowadays many projects are written according to the principle ‘the main is starting; further it goes on its own’. For example, I wrote one of my first projects basing on the 40 minutes long telephone conversation. And although everything functioned the risk of ‘falling down’ was big enough. Of course, if I had thought over and planned everything before starting to code, the risk of fails’ appearance would have been considerably less. For example, abstraction in the project was nearly equal to zero. I.e. if customer had had a wish to use MySQL instead of MSSQL, we would have to rewrite the whole project. Besides that the safety system wasn’t done properly. All data were saved in cookie. There were some other defects but they were too inconsiderable to be described in details. In his work "The Mythical Man Month" which was devoted to the software development process Fred Brooks described optimal plan for work over an application that looks like that: But nowadays we are already happy if we can spend 1/6 of all the time on the first part (projecting). In the most cases programmers are eager to print code without having a clear idea of what they should write and without considered task estimation and, of course, without any ready-made ways of its solution. Such behavior can be compared with attempts to write a term paper without setting up a plan. Coding can be a simple statement of what you’ve already have projected, no more than this. Many programmers come to such grade when they write all the application (or the most difficult parts of it) in pseudocode and only after it code the project in the real language such as, for example, PHP. Notice: projecting of appearance, work and ‘thinking’ of your application is also known as informational architecture. Stages of project’s development A lot can be said concerning this theme. But it’s enough to enumerate: debugging, compiling flow blocks, modeling, project management and terms establishment. But we will content ourselves with a minimal set of general recommendations. So an ideal project’s plan includes: Stage of demands’ learning Complete analysis of demands made to the program is the first step in planning of an application; you define what exactly you need to do. You describe detailed and precisely what the program will do and how it will work. It’s one of the principal moments in development. Determination of users’ demands So how can you clear up what exactly a customer expects from your application? You should play a role of consultant occupied with determination of customer’s needs and in particular try to analyze what this customer presents himself. For example, you should be interested in following: The last question enumerated will be able to help you with the project’s extension. Can you offer some optional functionality and thus make their site better? If you can, your customer will be extremely happy and you’ll have the opportunity to deal with a big project (and it also costs more). Methods of research can vary from questionnaires to the private conversations with people occupying key positions in the company. But whatever you choose it’s always very important to ask all the questions enumerated in this chapter. Determination of technological demands On the given stage you are to determine which technologies your application will use. The main question: will we be able to satisfy customer’s demands; do we dispose of technical ability for this? At this you should take into account language in which the application is realized, operating system of a platform, server’s speed and speed of connection with it and many other aspects. Stage of development So the specifications are ready. On the given stage you should decide how your application will be realized, what and when will occur in it. You may even make some rough drafts in pseudocode if some parts seem too complicated to you. In other words you’ll need to: To model Before you start coding you should think over the way in which different parts of your application will communicate with each other. As an example we’ll examine a script with message sending form. We’ll describe all possible actions which user can make for filling in such a form. On the highest application’s abstraction level only two actions are possible: a user either has sent his data or hasn’t sent them. If the data aren’t sent, you need to send a page with an empty form to the user. In other case it’s necessary to make (to repeat) one of the following actions: To illustrate Below a very simple diagram illustrating application’s work is presented. The diagram is made in Microsoft Visio(r) and suits ideally for the simple message sending application. However when we speak about more complicated projects it’s always useful to have special tool for diagram building available. Here are three of them enjoying the most success: Dia, Visio and UML. Pseudocode Pseudocode (i.e. such code which only describes an application’s work and isn’t correlated with any of the languages) is a rather common practice among developers. Usually it is used when some confusing situations are faced or when the general overview of application’s work isn’t clear. I also think that pseudocode is rather useful by the applications’ interfaces determination and especially when interfaces I have created are used by other developers. Pseudocode helps to find the simplest but at the same time sufficient methods of treating this or that application part. To give an example we’ll return to our script for messages sending: This code determines the main script’s structure and demonstrates all the necessary elements. Of course, code isn’t a working PHP-script (although it could take this place). The mission of pseudocode is to set tasks and, perhaps, to base them on theory. The grade of pseudocode’s abstraction depends on you only. As for me, I incline to less abstract code. It depends on that how sure you feel when programming. And finally when you’ve already planned your application you can start coding: all the steps that should be done are already familiar to you; you also know what you should get as a result. Stage of testing One of the most important stages in the applications’ development which nevertheless is not very often done is (final) testing. Often under pressure of a manager or due to the time shortage the testing phase is reduced to minimum or omitted at all. And the application is considered to be ‘conventionally fit’. Frankly speaking, programmers hate testing. This, perhaps, is the most annoying and irritating occupation connected with programming. Testing results into hours and days of unknown bugs hunting, debugging, checking of all the possible combinations and situations – and all this in order to make sure that the program functions properly in the most cases. And nevertheless you are NOT GOING to get a code without any bugs! Something is sure to slip away from your attention. And things which (you are sure!) shouldn’t happen occur at any case. Regression tests People are seldom content themselves with one application’s version: most of them are in perpetual endless renewal. Make sure that adding new functions doesn’t distort work of the old ones: functions on which users depend to a certain extent. To do this you should know about such notion as ‘regression tests’ cycle’. So are called tests which prove that functionality of the present version won’t be upset in the following release. Each new version of PHP-project itself passes series of regression tests and thus by adding some innovations the previous functionality is saved completely. Thus we not only achieve backward compatibility of all PHP-versions (i.e. new abilities added but the old scripts keep working correctly) but also confirm the fact that innovations don’t upset work of other functions (and even don’t change their behavior). Volume tests Congratulations, your application works perfectly with one user: everything seems to go right and happen at a huge speed. And what happens if 20 users will work with the application simultaneously? And 30 users? And what about 100? How fast is your project working now? Does it show up strange errors? Independent from the tests you do make sure that your project works correctly at big loadings and changing conditions. But this doesn’t mean that users should do all testing work instead of you (when you simply lay out everything on the site and wait for references and letters about the errors found, you know…). Make beta-testing as it is described in the previous chapter. Besides that there are special service programs which emulate big users’ flow. The first thing to memorize is AB from Apache. AB or Apache Benchmark makes adjusted quantity of requests to the page and shows up quantity of successful requests, quantity of requests failed, average speed and so on. We recommend you insistently to test your web-projects by means of AB (of course, if you’ve made a decision to use Apache server). This way you’ll be able to find and optimize pages which ‘eat up’ memory or load to long. (Also think about purchasing of a wonderful caching utility from Zend- The Zend Cache). Error number one for all time and nowadays which is haunting programmers is complete inability to calculate their time inputs. Don’t be afraid too much because we are all optimists. It’s quite natural to suppose that realization of a project will take exactly that period of time which it has to. And no bugs are taken into account. Even more than that, we often have no idea that we might have any problems with realization of something. So let’s pull ourselves together, suppress this instinct and calculate time inputs otherwise. From my personal practice: when I take up a new project I take into account all the factors I can memorize, estimate period of time I need for each of them, sum all this up. Then I double the result I got. Isn’t it accurate? I wouldn’t say so: customers are pleased when you bring a ready-made project before the indicated term (and conversely: if you are late, they are rather displeased). Such ‘reassurance’ method of time inputs’ indication helps me to work properly over a project and keep within terms indicated by me. But here, of course, everything depends on the accuracy of the original calculations. Every programmer underestimates (far more seldom – overestimates) time which he needs for a project’s development. At this each of them has his own coefficient of potential errors admission. For me it’s 2, for someone t can be 1.5 and for someone else even 3. The whole trick consists in finding your personal coefficient and amending your calculations. Underestimation of time inputs for the project’s development can result into following consequences (which are too familiar to me): Always leave enough time for prolonged checkout (the same period as you leave for the whole coding stage and even more) and no less than one third of all the time for planning. These two stages determine the whole project’s development. SterlingWonderfulToyland.com: Example Let’s examine as an example one simple project: site SterlingWonderfulToyland.com. This is a usual commercial internet-site. Its purpose is to sell via internet game devices and videogames with discounts; the items quantity is limited. As a supporter of old and checked sales’ methods the site’s owner John Giuseppe wants to invite customers to his storehouse and choose goods themselves. Thus the whole site can be logically divided into two parts: By planning I would make up two separate estimates for those parts. Then I would sum up these two terms, add a week for assembling two parts and presented the final term to the customer (for the whole site without any division). Html-part For simple strategic part of the site I would taken as base the time I need to make up one page in some editor, for example, in Macromedia Dreamweaver. And as dynamic elements are absent in this part for determination of general time input you may simply multiply time you need to make up one page by the quantity of pages (under condition that pages’ design is already developed). Then I would double the result I got (as my personal coefficient is 2). Generally, this part doesn’t need really detailed planning (think over: a designer submits you with schedule of that how everything should look like, your task is to make up pages in Dreamweaver). Notice: add one more interval which is equal to about 1/3 of all time, you’ll use it for assembling of the project. So if you’ve planned development of script for credit cards checking in 9 days, add another 2-3 days. Orders’ system Distribution of regalement for dynamical part is rather difficult thing. The thing that can help you here is simple division of task into some simple components (as, for example, operations with credit cards, instant order at one click, products’ catalogue, management system of this catalogue and so on) and calculation without any coefficient. Then I sum up and multiply by my personal coefficient of errors admitted. Only after that I calculate one third of time for the whole development and add it. All the optional time I spend on checkout and testing in order to provide a customer with a correctly working project. Notice: add another one third of the time for planning as in simple html-part. How to present such terms to the customer The fact you’ve managed to calculate the terms for project realization correctly doesn’t mean that the customer accepts them as you do. Sometimes having indicated too long terms you simply loose your customer. Your competitors will set more attractive terms only to get this order and they simply won’t hold within these limits. So what should you do to please the customer and at the same time be honest and hold within indicated terms? Here the moment comes when you have to present your services and terms to the customer in a proper way… Which terms can you offer? What makes your terms real and why exactly this term is indicated instead of any other one? Often imagined conversation with the customer helps: imagine yourself on his place and think what you could expect from the potential employee. Here are some of the aspects which seemed the most important to me: If the terms indicated by you are too short If a nuisance like this has nevertheless happened to you and you are going to be late, there are still some possible variants of actions (which aren’t mentioned too often in such situations): PROGRAMMING BY MEANS OF METHOD ‘CUT-PASTE’: WRONG APPROACH. Usually copying of someone else’s code isn’t considered to be a very good idea. It’ll be great to examine techniques and algorithms of another code and integrate them into your project if necessary. Or you can use ready-made libraries. But you shouldn’t simply copy another code. ABSENCE OF TECHNICAL DIRECTIVES IN THE PROJECT Making up detailed directives is necessary by developing every project. Directives let you lead your project organized in the style and documentation which is common for everyone and thus let you evade many probable ‘misunderstandings’ in the future. ABSENCE OF EXPERT APPRECIATION OF THE PROGRAM. Someone is obligatory to look through your code. New look on the project will find such things as non-optimized SQL-requests, wrong syntax application, too complicated solutions, ‘holes’ and other drawbacks. ‘HOLES PATCHING’ Serious drawbacks cannot be corrected with ‘patches’. If you see that something has been projected wrong (or in a way that isn’t proper enough), in the most cases it’s better to reproject and rewrite this module. EXCLUDING OF AN END-USER FROM THE DEVELOPMENT PROCESS. Never do this. These are namely users who will judge about appropriateness of your application when everything will be said and done. Attraction of users to the application’s development process itself will let you evade many probable ‘misunderstandings’. ABSENCE OF A PLAN. Forget about principle ‘the main is to start; further it goes on its own’. Find time for detailed planning. Each project’s plan should include following stages: examining of demands, development and testing. FOULED-UP TERMS. Find enough time for the project’s realization! Aiming at keeping to the unreal terms you’ll increase your chances for making previous 20 errors. Don’t let yourself be wasted in time.
/*
+-----------------------------------------------------------------------+
| PHP version 4.0 |
+-----------------------------------------------------------------------+
| Copyright (c) 1997, 1998, 1999, 2000 The PHP Group |
+-----------------------------------------------------------------------+
| the given file with the source gets under action of PHP license |
| for version 2.02 which copy is saved in the given program package in file |
| LICENSE; the given license is also available on the address in WWW |
| http://www.php.net/license/2_02.txt. |
| If you haven’t got the PHP license copy and don't have any possibility |
| to get it through WWW we beg you to inform us on the address |
| license@php.net and the license will be immediately sent to you. |
+-----------------------------------------------------------------------+
|\Authors: Sterling Hughes <sterling@php.net> |
+-----------------------------------------------------------------------+
*/
/*
* Local variables:
* tabulation width : 4
* main indent C: 4
* Tabulation:
*/
5. Absence of the expert judgement about the program
4. ‘Patching up’ a project
<?php
$GeorgeBush = "If you examine market tendencies, I think, you’ll mention
that the larger import part comes into the USA from abroad ";
for ($idx = 0; $idx < strlen($GeorgeBush); $idx++) {
print $GeorgeBush[$idx];
}
?>
3. Excluding of ultimate user from the development process
2. Absence of a plan
if (formSubmitted) {
valid_name(name) or error() and output_form();
valid_email(email) or error() and output_form();
valid_message(message) or error() and output_form();
message = name & email;
send_mail(email, message);
print "Thank you for your feedback";
} else {
print "Send us feedback";
formelement(name);
formelement(email);
formelement(message);
}
1. Fouled-up terms
Summary
