Home

Table of Contents

1. Feature List (Current)
2. Standards
3. General Programming
4. Database
5. PHP Classes
6. The views
7. HTML and CSS
8. Javascript
9. Github
10. Tests
11. Database Model

Feature List (Current)

1. Login - (Password management still missing)
2. User Management - Create, Read, Update and Delete
3. Patient Records - Create, Read, Update and Delete
4. Lab Sections - Create, Read, Update and Delete
5. Test Types - Create, Read, Update and Delete
6. Measures - Create, Read, Update and Delete
7. Specimen Types - Create, Read, Update and Delete

Back to Top

Standards

General programming

1. All indices should zero based. e.g. if a element has sequential numeric values these would be from the series 0,1,2,3,...

Back to Top

Database

1. Naming

• table names, column names: all lowercase, use underscores to separate words e.g specimen_id, test_type_id
• names with abbreviations may be treated differently e.g. targetTAT makes more sense
• better long names that makes sense

1. Use of appropriate field type e.g. ‘SMALLINT’ instead of ‘STRING’ for age
2. If a primary key is necessary on a table it should be the first column and should be named 'id'. It should be unsigned.
3. When this id is referenced in another table (as a foreign key) it should be called 'tablename_id'
4. Table names are in the plural e.g. specimens instead of specimen
5. Create a migration file for every new table or change to a table. If necessary add the seed data using a separate file. See the Migrations & Seeding section of the online Laravel guide.

Back to Top ##PHP Classes This applies to Controllers, Models, migration and seeding classes, ...

1. Class names always begins with uppercase e.g. CreateTestTypeMeasureTable
2. When combining words every word begins with uppercase. Do not use underscores e.g. SpecimenType as opposed to Specimen_type
3. Method or Function names begin in lowercase and words join in uppercase e.g. getSpecimenTypes()
4. Provide descriptive class and function comments before their definitions
5. Variable names - begin in lowercase. Multiple words should begin in upper case e.g. specimenType
6. Better long names that makes sense e.g. specimenType instead of speTyp
7. Soft delete(s) preferable to hard delete(s)

Back to Top ##The views

1. Using blade templating engine
2. All html elements in lowercase
3. Using bootstrap for css

Back to Top ##HTML and CSS

1. All CSS should be placed in an external stylesheet file (public/css/)
2. CSS class names should use hyphens when joining words e.g. ‘user-image’
3. Indent for readability in order of precedence e.g.

  form-group{}
  .form-group.actions-row{}
      .form-group > label{}
      .form-group .form-control{}
      .form-group .form-pane{}
          .form-group .form-pane label{}

1. Never use !important;
2. CSS files should have categorised sections e.g. for user files, for general layout
3. Use contextual elements such as <strong> and <em> instead of <b> or <i>
4. Page layout should be done from the CSS file. Do not use &nbsp; for spacing. If done properly there should be no need to use <br> either.
5. Comments: Include the section name e.g.

 /**
  * forms
  */

Back to Top

Javascript

1. Using jquery
2. All javascript code should be in external files (public/js/)

Back to Top

Github

1. Create an issue for each change you want to make.
2. Create a branch from the master for the same change. The branch name should be descriptive
3. Once fixed, create a pull request asking a specific person to review the feature.
4. Reviewed and approved features should be merged back to the master and the branch deleted.

Back to Top

Tests

1. Every feature should have an accompanying test
2. A feature should pass all tests before it is merged into the master branch

Back to Top

Database Model

Download: PDF PNG MWB

Back to Top