Coding Standards

Coding Standards

General programming

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

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
2. Use of appropriate field type e.g. ‘SMALLINT’ instead of ‘STRING’ for age
3. If a primary key is necessary on a table it should be the first column and should be named 'id'. It should be unsigned.
4. When this id is referenced in another table (as a foreign key) it should be called 'tablename_id'
5. Table names are in the plural e.g. specimens instead of specimen
6. 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

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

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
  */

Back to Top

Javascript

1. Using jquery. Do not introduce any new libraries.
2. All javascript code should be in external files (public/js/)

Back to Top

Git

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] (http://archive.robwilkerson.org/2010/03/02/git-tip-ignore-changes-to-tracked-files/).

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

Feature completion check list

1. Have you written tests for the models and controllers as applicable?
2. Have you added Access controls as applicable?
3. Have you updated the wiki with relevant info about the feature? You can create a markdown file as that will be added to the wiki once your changes are accepted.

Back to Top