Standards

General programming

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

Database

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.

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)

Laravel views

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

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{}
   

4. Never use !important;

5. CSS files should have categorised sections e.g. for user files, for general layout

6. Use contextual elements such as <strong> and <em> instead of <b> or <i>

7. 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

8. Comments: Include the section name e.g.:

   /**
    * forms
    */
   

Javascript

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

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
5. You can link to a line of code, or a section of code by reading here
6. There are config files that you want to change but don’t want to commit, i.e /app/config/app.php and /app/config/database.php you can prevent yourself from accidentally commiting these files by doing git update-index --assume-unchanged /path/to/file.ext your changes will no longer be tracked. [Read more here]

Tests

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

Feature check list

[ ] Tests for the models and controllers where applicable

[ ] Adding Access controls where applicable

[ ] Updating the wiki with relevant info about the feature

Database