DEPARTMENT OF LOCAL GOVERNMENT & HOUSING

Project Naming Conventions & Organizational

Guidelines
PROJECT : ALL DLGH PROJECTS

SUBJECT : ALL PHP PROJECTS

TITLE : PROJECT NAMING CONVENTIONS & ORGANISATIONAL FOR

ALL PHP PROJECTS

Author: Jonty Esser

File Reference: \\10.156.55.218\data\spmt2\project_data\naming_guidelines\

all_php_projects_naming_guideline_04082009_V1.doc

Document Ref
No:

Version: 1.0.0

Date Created: 8/4/2009 1:20 a8/p8

DOCUMENT APPROVAL

Document approval constitutes affirmation by the originators of this document that its
contents are correct and validated to the best of their abilities.

Name Position Signature Date

Page 1
DOCUMENT ACCEPTANCE

Document acceptance constitutes affirmation by the customers of this document that its
contents meet agreed requirements, and may be used by other parties as valid input.

Name Position Signature Date

PROJECT TEAM

Name Position
Ms I Mabaso Project Leader
Ms P Lekgau Project Manager
Ms G Maboa Project Assistant
Mr J E Esser System Developer
Mr J de Bruyn System Developer

Page 2
Table of Content

1. Purpose of the document......................................................................................4

2. File server...........................................................................................................4
3. Project_files directory structure and naming convention...........................................6
4. Naming conventions & labeling..............................................................................8
4.1 Date sensitive naming convention....................................................................9
5. Formatting convention for code files.......................................................................9
5.1 Commenting.....................................................................................................9
5.2 Code comments..............................................................................................10
5.3 New Sections within the files.........................................................................10
6. Version control and backup procedure..................................................................11

Page 3
1. Purpose of the document

The purpose of this document is to outline GITO Network Organizational Guidelines. It

provide an overview of network connectivity and best development practices. This
document can be shared with everyone.

2. File server

Server Path: \\10.156.55.218\data\

The File server can be accessed from computers connected to the domain directly on-
site. One can access the server by pointing explorer to \\10.156.55.218\data\
<-project_name-> or by going to the START Menu > Run > Open:
\\10.156.55.218\data\ <-project_name-> .

Here is a brief description of each share and its purpose:

portfolio portfolio

A collection of all projects completed previously

<-project_name->/branding_&_identity

Contains DGLH logos, style guides, branding, identity and marketing materials.

<-project_name->/company

Contains HR Related and other company files.

<-project_name->/creative&technical_resources

Contains collections of Images and Links used as resources or references by the

Page 4
 development teams.

<-project_name->/installs

Contains installation files for various programs. Please contact the network administrator
to obtain a license for your computer.

<-project_name->/it

Contains files, drivers and documentation used by the Information Technology

Department

<-project_name->/project_data

Contains Project Data used by Project managers, including legal agreements, project
plans, budgets and schedules and statements of work. Project Plan file will follow a strict
save as procedure with the following format ->project name<-
<-_project_plan_ddmmyyyy.mpp example as follows pmt_project_plan_18012009.mpp.

<- project_name ->/project_files

Contains project files used by the creative and technology teams, such as Photoshop files,
Flash files, documentation and client assets.

<-project_name->/webdev

Development files

Page 5
3. Project_files directory structure and naming convention

A well organized folder structure with clear naming conventions is critical for internal and
client communications. This reduces errors, distractions and duplication of efforts. It is
the responsibility of all team members to ensure organization on-the-fly so things are
organized and labeled properly at all times and should not be put off for later, or for
someone else. This document is designed to resolve some of the following common
issues and is largely based on common sense. This document should be able to answer
these questions:

I need to upload the latest build, but I don’t know what’s needed and what’s not.
• Where is the latest comp? I need to send this out ASAP to the client!
• Where can I find the latest spec document so I can update it?
• Where is the latest QA spreadsheet with all revisions so I can add new comments?
• Which one is newer? The PSD or the ZIP with the same filename?

And it should also significantly help with:

• Making sure everyone is always working or updating the latest file

• Archiving and Restoring only necessary files and folders from your Backup
• Client Project Delivery CD containing only final files, thus eliminating confusion
• When updating your portfolios, it will be a snap adding a new projects

All newly created files should start with the <-project_name-

>_<document_name>_<date>_<version>. Here is an example
spmt_charter_01022009_v1.doc. A .pdf file will be created for documents that
are finalized and signed off no changes after this file is created.
spmt_charter_01022009_v1.pdf

Project Level: <-project_name-> Folders

Once inside the <-project_name-> folder, the user should ALWAYS comply with the

Page 6
 version control and naming conventions stipulated in this document.

<-project_name->/webdev/
Projects Files root for website

<-project_name->/webdev/core/archive

<-project_name->/webdev/core/menu

<-project_name->/webdev/core/php_plot

->project_name<-/webdev/core/reporting

->project_name<-/webdev/core/script

->project_name<-/webdev/core/stylesheet

->project_name<- /webdev/includes/attachments

->project_name<-/webdev/includes/backup

->project_name<-/webdev/includes/downloads

->project_name<-/webdev/includes/images

Page 7
 ->project_name<-/webdev/includes/logos

->project_name<-/webdev/includes/pages

->project_name<-/webdev/includes/reports

->project_name<-/webdev/includes/temp

->project_name<-/webdev/psd

4. Naming conventions & labeling

The file naming convention should be simple, logical, intuitive and straight to the point.
Projects often require file dependencies where spaces in filenames and case sensitivity
can be an issue. Therefore the webdev/->project_name<- folder for all projects
have unique requirements:

• All required for launch sub folders are all lower case, and spaces are defined with “_”
• Only deployment files are to be organized in logical folders. ActionScript class files
(.as) should not be posted, nor should be FLAs, PSDs or other source files.

Single word files names are lowercase

All filename details are separated by “_”

singleword.filetype – webdev/->project_name<-
• main.php
• home.swf
• gadgets.html

Page 8
mulitiple_object_action.filetype – webdev/->project_name<-
• quotations_print_list.php
• quotations_print_view.php
• quotations_print_delete.php

webdev/->project_name<- Version Naming Convention

Developers and user should at all times, before opening a file to develop, save the file in the
same folder with an a_filename.file extension.
• The file you wish to change is - quotations_print_list.php
• You need to change the file to the following – a_quotations_print_list.php

4.1 Date sensitive naming convention

Some date sensitive documents, such as QA reports should have the date attached to the
end, in addition to a revision number:
• ClientName_ProjectName_ddmmyyyy_v1.XLS
(example: charter_pmt_21012009_v1.xls)

5. Formatting convention for code files

5.1 Commenting

Please note that any core file will have a comment as follows in it, do not
change core files as this will cause unnecessary testing, errors and
redevelopment.

/****************************************************************
*
* DO NOT CHANGE OR DELETE THIS FILE
* this is a CORE FILE
*
****************************************************************/

All php files should be created with the following comment at the top of the page in the
same format as shown below

Page 9
/************************************************************************
* Author: JM de Bruyn
* Creation Date: 2009-01-22
* Version: 1.0
* Pages Role: Queries DB for reports pass dead line and
* emails the correct managers a reminder
* Date Changed: 2009-01-22
* Changed By: Jonty Esser
* Reason for change: Call new function and include new file email.php
*
************************************************************************/

5.2 Code comments

The following is and example of the standard method to comment within the php code.

Statements:

Statements like “if, elseif and while” ect should be commented in the following format

Example CODE START

if ($THErandomNUMBER <= 10) { // Comments for this section

$THErandomNUMBER = 10;
}

Example CODE END

5.3 New Sections within the files

Before starting a new section within the code the following comment format should be
used

Example CODE START

$THEloopAMOUNT += 1;
$DOx += 1;
}

// Comments go here before starting another section

echo $THEloopAMOUNT . "<br>";

echo $DOx . "<br>";

Page 10
Example CODE END

6. Version control and backup procedure

Version control procedure - Macro management

All files will start with the version number 1.0000 added in the comment section –
format explained above in comments. A version change will not be initiated until the first
release is live and a system version release document has been released and completed.

Changes to the version numbers after the decimal 1.0010 will illustrate a minor or
working change, and should be explained in the comment section under the topic
Reason for change:

Additionally any major change and or bug fix that is required will change the first
number after the decimal 1.0100 and should be explained in the comment section under
the topic Reason for change: with an addition to the beginning of the comment with
major change or bug fix then detailed explanation. E.g. Reason for change: Bug Fix –
Query selected user id and should select user name from database corrected and tested.

Version control procedure - Micro management Development Procedure

All developers should use the following procedure to manage files while developing.
If a file is to be created the comment should be filled in correctly from the start by the
creator of that file.

If the file exists and the developer wishes to change the file, the developer should create
a copy the file in the same folder and rename the file with an o_filename.php. The o_
prefix stands for original file. Additionally the developer that creates the o_ file needs to
add a comment in the comment block that he is working on the file and date.

For example -

/************************************************************************
* Author: JM de Bruyn
* Creation Date: 2009-01-22

Page 11
* Version: 1.0
* Pages Role: Queries DB for reports pass dead line and
* emails the correct managers a reminder
* Date Changed: 2009-01-22
* Changed By: Jonty Esser
* Reason for change: Call new function and include new file
* email.php
* Opened by: Jody de Bruyn
* Date Opened: 2009-01-23
************************************************************************/

If an o_ file exists for a file that you wish to do work in the developer needs to open the
file to see in the comments who is working on the file and get permission from that
developer. No file is to be deleted.

Back Up

A back-ups should be done every day of both shared folders, this should be a scheduled
task that needs to be setup by the server administrator.

@@@@@@@@@@@@@@@@@@@ THE END @@@@@@@@@@@@@@@@@@@@

Page 12