Escolar Documentos
Profissional Documentos
Cultura Documentos
Contribution:
16 32 %
16 23 %
16 23 %
16 23 %
16 23 %
16 23 %
September 8, 2014
Student number:
u12097722
u12007227
u12023796
u12066754
u11198908
u11092743
DECLARATION OF ORIGINALITY
UNIVERSITY OF PRETORIA
The University of Pretoria places great emphasis upon integrity and ethical conduct in the preparation of all
written work submitted for academic evaluation.
While academic staff teach you about referencing techniques and how to avoid plagiarism, you too have a
responsibility in this regard. If you are at any stage uncertain as to what is required, you should speak to
your lecturer before any written work is submitted.
You are guilty of plagiarism if you copy something from another authors work (e.g. a book, an article or a
website) without acknowledging the source and pass it off as your own. In effect you are stealing something
that belongs to someone else. This is not only the case when you copy work word-for-word (verbatim), but
also when you submit someone elses work in a slightly altered form (paraphrase) or use a line of argument
without acknowledging it. You are not allowed to use work previously produced by another student. You
are also not allowed to let anybody copy your work with the intention of passing if off as his/her work.
Students who commit plagiarism will not be given any credit for plagiarised work. The matter may also
be referred to the Disciplinary Committee (Students) for a ruling. Plagiarism is regarded as a serious
contravention of the Universitys rules and can lead to expulsion from the University.
The declaration which follows must accompany all written work submitted while you are a student of the
University of Pretoria. No written work will be accepted unless the declaration has been completed and
attached.
Name:
W Nel
G Scheepers
J Prinsloo
K Cowdrey
K Pitzer
C Swanepoel
Student Nr:
u12097722
u12007227
u12023796
u12066754
u11198908
u11092743
Contents
1
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
1.2
Reserved words . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Directory layout . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Commenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
Variable declaration . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Logic If Statements . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Indentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
Line Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5
General Guidelines
1.1
The source code of a class or main file which is written should always consist of a header file
containing all of the functions available in the C file and also contain sufficient comments
as to what each function does and how it works. The exact format will be specified later in
the coding guidelines.
When creating new source code files, the following format should be followed for the relevant
files:
C++ Code file : filename.cpp
C++ Header file : filename.h
Makefile : MakeFile
Makefile
Only one makefile will be used to compile the software and when testing the software parts,
the Makefile name should remain the same.
1.2
Reserved words
The following words are reserved C++ words and should not be used to name objects,
variables, constants etc.
bool
catch
class
const cast
asm
delete
dynamic cast
explicit
export
compl
friend
inline
mutable
namespace
false
new
operator
private
protected reinterpret cast
template
this
throw
true
static cast
try
typeid
typename
using
virtual
and
and eq
bitand
bitor
wchar t
compl
not
not eq
or
or eq
xor
xor eq
Table 1.1: Add caption
1.3
Directory layout
Makefile - The makefile should be contained in the root of the project directory
src - This directory should contain all the C++ source code file which is used by this
application
include - This directory should only contain the header files being used by the C++
files
backups - YYYYMMDDHHMM - This is an optional directory which can be used to
store backups of source code it is recommended at intervals of 1 hour. This is very
helpful when a developer may have mistakenly deleted a segment or part of the code
without noticing it and then the undo stack would have overflown, resulting in lost
data. This directory contains the makefile and both of the directories containing the
source code.
1.4
Commenting
Single line comment methods should be avoided as far as possible and only be used if only
one line is necessary.
The following rules apply for commenting
Double asterisks should be used when starting and ending the comment block
Sections should be indicated clearly to allow easier maintenance
Sections are indicated with 20 dashes and then the section name should be centred
and also ending with 20 dashes
i.e. /**- Private Variables -**/
Each variable should be described by comments
1.5
2
2.1
Naming Conventions
Variable declaration
2.2
Constants
Constants should only contain uppercase letters and a space should be indicated by an
underscore i.e. A CONSTANT
2.3
Functions
Function Names contain mixed case and should start with an uppercase letter. i.e. FunctionName
Functions will be avoid ambiguity as far as possible, rather name a function IsValid() than
Validate() where the meaning is unclear.
3
3.1
Typography
Style
3.2
Logic If Statements
Avoid unnecessary curly braces, but if one branch of an if is braced, then the other should
be too.
3.3
Indentation
Each indention should be 4 spaces and preferably the IDE should be set that a tab is 4
spaces.
3.4
Line Length
Lines of code should be no longer than 60 characters and if strings are longer than this it
should be split up in parts.
3.5
No errors or warnings should be present when deploying the software. If any warnings are
present, they should be resolved even though they do not actually change any functions or
performance of the application.