Jump to content

Practical Project: Technical Solution

From Wikibooks, open books for an open world

UNIT 4 - ⇑ The Computing Practical Project ⇑

← Design Technical Solution System Testing →


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

[edit | edit source]

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

[edit | edit source]
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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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

[edit | edit source]

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