Department of Electrical, Electronic

and Computer Engineering

EPE 321 - Software Engineering

Coding Guidelines - Contract

Bridge
Author:
W Nel
G Scheepers
J Prinsloo
K Cowdrey
K Pitzer
C Swanepoel

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

Topic: Design Specifications - Contract Bridge

Declaration
1. I understand what plagiarism is and am aware of the Universitys policy in this regard.
2. I declare that this assignment report is my own original work. Where other peoples work has been
used (either from a printed source, Internet or any other source), this has been properly acknowledged
and referenced in accordance with departmental requirements.
3. I have not used work previously produced by another student or any other person to hand in as my
own.
4. I have not allowed, and will not allow, anyone to copy my work with the intention of passing it off as
his or her own work.

Contents
1

General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1

Source Code Files . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Reserved words . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Directory layout . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

Commenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5

The Standard Library . . . . . . . . . . . . . . . . . . . . . . . . .

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

Errors and warnings . . . . . . . . . . . . . . . . . . . . . . . . . .

General Guidelines

1.1

Source Code Files

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

The Standard Library

Try to use the standard library of functions as far as possible.

2
2.1

Naming Conventions
Variable declaration

Will be made with camelCase i.e. theVariable

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

The coding style that will be adhered to will be:

i n t main ( void )
{
c o u t << H e l l o World ! ;
}

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

Errors and warnings

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.