Practical Project: Technical Solution

This is the real thing, where you get marked on the code that you have written. Notice that the program without any writeup is worth only 31% of the overall unit. However, you need this section to complete the other parts of the project and this section will almost certainly take you longer than any other section of this Unit. Below are a couple of quick tips on getting top marks in this section plus some links to programming help guides:

Don't just use built in functions

In the good old days students could get a decent mark by making a project in Access and using wizards to do all the functionality. This is no longer the case and if you do that you will get a very low mark. You must write your own code and sub routines. Handing in page after page of automatically generated code will get you no marks. Write your own algorithms and take credit for it!

(Database) Normalise Data

Two related entities shown using Crow's Foot notation

Make sure that all your database tables are normalised. If they aren't you will lose marks in the Design Section and your project will be very hard to get working. A quick way to test this is to see if your E-R Diagram only has 1-Many relationships. If you use anything else then you will be running into trouble.

(Object Orientation) Make sure you use Encapsulation appropriately

If you are building your own code classes make sure that you don't allow users direct access to any variables and that they use the appropriate get and set routines. Don't make everything public! If you can, use inheritance. By implementing these things you'll find the exam much easier.

Use sensible variable datatypes

Make sure that the datatype you use are sensible. You will get marked down for using the wrong datatypes in your database tables and variables.

For example: If you are recording the total number of chocolate bars in a shop you don't need to use a Long or Float, you can only have whole numbers of chocolate bars and it is unlikely you'll have over a few million items. Use an Integer!

Use sensible variable names

If you are using variables to store things they must have a name that makes sense so you know what it does when you read its name in your code.

For example: If you are recording the total number of chocolate bars in a shop you don't want to use a name like variable1. What does variable1 mean? Use a sensible name such as NumChoc.

Use sensible Function/Procedure names

If you are creating subroutines to process things in your code make sure you give them a sensible name so that people know what they are doing when they see them in the code.

For example: If you have written a piece of code to calculate the average price of a chocolate bar then don't call it FunctionA(), what does FunctionA() mean?! Call it ChocAverage().

Try to stick to one naming convention

If you are using lots of variable names and function names, stick to a single style for naming them. If you use lots of different conventions things are going to look ugly. Wikipedia guidance

For example:

• firstName, lastName, calculateDoB, numLegs
• FirstName, LastName, CalculateDoB, NumLegs
• First_Name, Last_Name, Calculate_DoB, Num_Legs

Don't make your names too long

Long variables can be very hard to read and much easier for you to make mistakes when writing them, try to shorten things where possible.

For example:

Too Long	Just Right
ThisIsYourFirstName	FirstName
the_value_of_a_chocolate_bar	ChocVal

When using forms prefix toolbox type

When you are using forms and lots of variables at the same time it can sometimes get very confusing whether you are talking about a variable price or the text box that stores the price. Get past this using prefixes:

Form Object	prefix	example
Text box	txt	txtFirstName
Button	btn	btnSubmit
Radio button	rdo	rdoOverEighteen
Check box	chk	chkAgree
Image Element	img	imgLogo
Timer	tmr	tmrLogOut
Label	lbl	lblIntroduction
Standard variable	[none]	ChocNumber

Indent your work

A lot of programming environments help to indent your code automatically and you should be able to find one for the language you are using. Indenting helps people to quickly read and understand your code as it clearly shows the structure of functions, procedures, selection and iteration statements. For example the following is very hard to read:

int main(int argc, char *argv[])
{
...
while (x == y) {
something();
somethingelse();
if (some_error)
do_correct();
else
continue_as_usual();
}
finalthing();
...
}

If you indent it, it becomes much easier to read:

int main(int argc, char *argv[])
{
    ...
    while (x == y) {
        something();
        somethingelse();
        if (some_error)
            do_correct();
        else
            continue_as_usual();
    }
    finalthing();
    ...
}

Use comments where necessary

Some of the best written code doesn't need comments because if you have structured it correctly and used all the proper naming conventions it should be pretty easy to read. However for the code you are writing you should put some comments to explain what each section does.

'this function takes an array of prices and outputs the average
function calculateAverage(num1(20) as integer)
{
    'add all the numbers together
    while ...
          ...
          ...
    end while
    
    console.writeline(average)
}

What to submit

You need to provide all the code that you have written. For each of your forms provide:

• Title
• Screen shot
• Code

For each of your modules/classes provide:

• Title
• Code

For any database tables you have made, provide screen shots in design view of mySQL or Access