470,851 Members | 1,184 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Share your developer knowledge by writing an article on Bytes.

Tutorial 2 - How to Program

9,065 Expert Mod 8TB
Posted by Banfa

The previous tutorial discussed what programming is, what we are trying to achieve, the answer being a list of instructions constituting a valid program. Now we will discuss how we set about doing that.

Every program starts with a specification, this may be a several hundred page document from your latest client or one small paragraph from your professor and pretty much anything in-between.

The specification is very important and specification writing is a whole sub-branch of programming that I am not going to discuss here. The important thing is that the specification is correct otherwise, to use a well know computing adage, garbage in garbage out.

An example of this happen to me several years ago, I had received a 10-20 page specification for a piece of Windows software. The specification seemed reasonable so I started work on it, the only thing I noticed was that in the program menu a word other than ‘File’ had been specified for the first drop-down menu despite the fact that contained sub-menu items such as Open, Save, Save As etc normally found on the File menu of a Windows program. I raised this point with the client and asked if they wanted to consider using the word ‘File’ instead for this menu that was clearly a File menu.

I got the response that they were thinking about it which they expected to take about 2 weeks and to do nothing in the mean time. Now remembering that I was younger, less experienced and less cynical back then I thought that they couldn’t possibly be changing that much of the specification and since I had little else to do I carried on working on it on the assumption that although it may require modification much of the work would be relevant and useful. This was a mistake when I got the new specification 2 weeks later there was not a single thing in it that bore any semblance of similarity to the original specification I received. I had to start over completely. This was a case of the specification being so wrong that a question about a single word in the user interface caused a complete change in the entire specification. I have to say that for me this is a unique example, I have never had a specification that wrong since that one.

As a programmer the specification is NOT your responsibility, remember your responsibility is creating the list of instructions that the computer will follow. However it is your responsibility to read and understand the specification. Where required you should raise questions on the specification if it is unclear, illogical or incomplete. Take this specification:

The program will allow the user to input 3 integer values. Having verified that the sum of the first 2 values is less than the third value the program will calculate the area of the triangle whose sides of the lengths of the 3 inputs. It will then print the area on the screen for the user.

So what is wrong with it? Stop and think here.

Well among other errors you might have spotted this specification is incomplete because it does not say what should be done if the sum of first 2 values entered are greater than or equal to the third value , it is illogical because if the condition that the sum of first 2 values entered is less than the third value is true then the values can not make up the side lengths of a triangle so no area calculation is possible and finally it is unclear because it does not explicitly say what should happen once it has printed the area for the user, exit presumably.

Specifications are rarely perfect and it is not at all uncommon for the specification to go through several iterations before being finally agreed on.

So we have the specification at this point having read it, it is now the programmers responsibility to make sure that they have all the information required to implement it. Note the specification will tell you what has to happen, not necessarily how to make it happen so this is the point where you would make sure that you know how to solve the problem as discussed in the last tutorial. Research on the web or in known standards and books is in-order here to make sure that you know how to solve the problem.

Having found out how to solve the problem you can then jump in and start coding, right? Wrong now is the time to do some program design, now how much design is required and where the design is stored is rather dependent on the complexity of the program, the experience of the user and the purpose of a program. For instance a simple program being written by an experienced programmer just as a temporary project tool (i.e. will only be in use for a day or 2) probably only requires a little thought about the program design. Where as any complex program being written by a team of programmers of varying experience will require a written design.

The amount of information in a design is a bit of a moveable feast, varying from a general description of how the program will hand together to a highly detailed design listing functions in the program and there purpose. There are many design methodologies available, pseudo coding, UML, YORDON, SDL for instance, and what you use is your choice.

Design may seem like an unnecessary stage, and I have had managers that have believed so and insisted that programming start without a design phase, but for each hour spent in design you will probably save well over an hour of programming time required in changing things.

The design, once you have it, is not set in stone. It is just gives the current ideas about how the program will be written. I do not think I have seen a project where the final code exactly matches the initial design. Also as the specification changes so will the design. But having it will give a clear place to start coding from and will ultimately lead to better more maintainable code.

Once you have a design it is time to start coding. However it is worth mentioning coding standards at this point. The coding standard you use is dependent on whoever is in charge of the project you work on; this may be you, your teacher, your manager or the company you work for. A coding standard is important, particularly when working in a team as it specifies the layout that will be used for the code as well as any features of the language that are not to be used (for instance on many embedded projects I have worked on with very limited memory the coding standard has specified that malloc shall not be used). The reason for having a coding standard is mainly maintenance again. Everyone using the same style to write their code means that everyone can more easily read each others code.

Finally once the program is finished you can begin testing. Now here is a question for you, can you define a successful test? (Think here)

The answer is slightly dependent on the purpose of the test but at this point, on the first version of the software the best definition I have seen is that a successful test is on that fails and highlights a bug that can be fix. The rational for this is that on any sizable project the probability that it has been written correctly first time is fairly close to 0. Therefore if it has bugs all a test that has passed has done is fail to highlight them.

A successful test does not mean the software is bug free, it just means your testing is not extensive enough.

Testing does not have to involve running any code. Source review by your peers is a good form of testing too. This is where you sit down round a table and go through the code line by line and examine it for logic errors, conformance to standards and programming errors. This can actually throw up errors that are not made obvious from testing the software by running it.

I could actually write as much about testing as I have already written so a will leave most of the subject for another tutorial, however I will say this. If you have an assignment from your professor which gives example inputs and outputs it is not enough to test with just those values. You can bet your bottom dollar that you professor will have a different set of test values to test your program with.

When deciding how to test some code you should look for the limit values and test those as well as some values in between. As an example take this function

Expand|Select|Wrap|Line Numbers
  1. short Example(short input)
  2. {
  3.     long output;
  5.     if (input < 0 || 1000 < input)
  6.     {
  7.         return -1;
  8.     }
  9.     output = (long)input * (1000L – (long)input) * 370L;
  11.     output /= 100000;
  13.    return (short)output;
  14. }
The specification for this function is as follows.

The function Example takes a single short parameter. If the value of this parameter is in the range 0<= parameter <= 1000 the function returns a value in the same range, otherwise it returns -1.

What test values should you use? (Think here)

Remember what I said, as a minimum you need to test the limits of the parameters. This function has 2 limits on its parameter, 0 and 1000, are those the 2 values you need to test. Well no, a limit like that defines 2 values, just inside the limit and just outside the limit so you need to test -1, 0, 1000, 1001, is that all not really because a short parameter has some limits of its own, minimum and maximum value as defined in limits.h SHRT_MIN (-32768) and SHRT_MAX (32767). So the complete set of limits to test is


Plus as I said you should check some numbers in the middle of the ranges, randomly say


In fact this is a fairly simple function and a 2 byte short only has 65536 possible values so it would be completely feasible to check every input value in this case but in many cases it is not possible to check every input value because there are too many. In this case being able to identify the limits is an important tool.
To summarise here is a diagram of the process of writing a program

Expand|Select|Wrap|Line Numbers
  1.           -------------------
  2.           |                 |
  3.   ------->|  Specification  |
  4.  |        |                 |
  5.  |        -------------------
  6.  |                 |
  7.  |                 |
  8.  |                 v
  9.  |        -------------------
  10.  |        |     Design      |
  11.  |<-------|   Including     |<-----------
  12.  |        | working out how |            |
  13.  |        -------------------            |
  14. Specification      |                     |
  15. Error Found        |                     |
  16.  |                 v                     |
  17.  |        -------------------            |
  18.  |        |                 |----------->|
  19.  |<-------|   Programming   |            |
  20.  |        |                 |<---       Design
  21.  |        -------------------    |    Flaw Found
  22.  |                 |             |       |
  23.  |                 |          Bug Found  |
  24.  |                 v             |       |
  25.  |        -------------------    |       |
  26.  |        |                 |----        |
  27.   --------|    Testing      |------------ 
  28.           |                 |
  29.           -------------------
As you can see at any stage you can go back to any previous stage and frequently do.

For those wanting gold stars here are some questions to answer
  1. What well known function does the function Example provide a very crude implementation of?
  2. In the function example why is the variable output a long?
  3. Why do I cast the parameter input to long before using it?
  4. Why is the following a bad test routine for the function Example? Can you correct it?
    Expand|Select|Wrap|Line Numbers
    1. int main(int argc, char **argp)
    2. {
    3.     short in=SHRT_MIN;
    4.     short out;
    5.     int good = 1;
    7.     for(in=SHRT_MIN; in<=SHRT_MAX; in++)
    8.     {
    9.         out = Example(in);
    11.         if (in < 0 || in > 1000)
    12.         {
    13.             if (out != -1)
    14.             {
    15.                 printf("ERROR: Example(%d) = %d, should be -1\n", in, out);
    16.                 good = 0;
    17.             }
    18.         }
    19.         else if (out < 0 || out > 1000)
    20.         {
    21.             printf("ERROR: Example(%d) = %d, should be in the range 0 - 1000\n", in, out);
    22.             good = 0;
    23.         }
    24.     }
    26.     if (good == 1)
    27.     {
    28.         printf("No errors detected\n");
    29.     }
    30. }
Nov 20 '07 #1
2 18470
Hi Every One

Could you please Explain me how to use return function

with examples please
Feb 26 '08 #2
In your example of the triangle, your should elicit requirements, such as should the criteria that input 1 and 2 be greater than 3 apply to all inputs.

For example, 1 = 100, 2 = 1, 3 = 2?
Jun 10 '08 #3

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

3 posts views Thread by Adolfo | last post: by
21 posts views Thread by Alf P. Steinbach | last post: by
156 posts views Thread by jacob navia | last post: by
11 posts views Thread by Magnus Lycka | last post: by
1 post views Thread by Max Wilson | last post: by
reply views Thread by Omar Abid | last post: by
182 posts views Thread by Bill Cunningham | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.