Skip to content

Coding Standards

Tim Kardol edited this page Apr 5, 2024 · 4 revisions

Versioning

Software releases of the website follow the following versioning scheme: YYYY.R.B

YYYY is the current year of the release. E.g. 2024

R represents the number of the release within a year. For example: the first release would be 1, second 2 etc.

B represents bugfixes that do not contain major breaking changes. For the first patch it would be 1, second patch 2 etc.

A full release could look something like: 2024.2.4

Branching

The conference development team makes use of different branches to help with development. To make sure that every team member is on the same page, the following standard has been developed to help with naming your branches.

Main

This is the main branch of the website. This contains the most recent working version of website code base. Merging to Main can only be done by administrators and an approved pull request.

Development

This is the branch where all new features are merged into. It is also the base branch from where a new branch is created. Merging back into development can only be done with an approved pull request.

Feature

When new features are to be added to the website a new feature branch must be created. The branch is named using the following naming scheme: feature/#id-feature-description

Rework

Sometimes we need to rework old features or pages. For this so called 'rework' branches are created. They use the following naming scheme: rework/#id-page-name, rework/#id-feature-name or rework/#id-feature-description

Bugfix

Bugfixes are also branched out from development. The branch is named using the following naming scheme: bugfix/#id-bug-description


Naming conventions

Models

All model should be in PascalCase, in singular form, no spacing between words.

Example: User, Timeslot, UserInvitation

Controllers

All controllers should be in PascalCase, in singular form, no spacing between words, and end with "Controller".

Example: UserController, RoomController, ContentModeratorController

Database

Migrations

Two types of migrations will be used - create migrations and update migration.

  • The create migrations should follow the standard naming create_table_name_table but artisan takes care of it. When creating a table make sure that the contents of it are between id and timestamps.

Example: create_password_reset_tokens_table (Laravel will add a timestamp in the beginning of the name automatically)

  • The update migration should follow the standard naming [action_on_that_table]_table_name_table

Example: add_two_factor_columns_to_users_table (Laravel will add a timestamp in the beginning of the name automatically)

Tables

Database tables should be in snake_case (undescore to separate words), lower case and should be in plural form.

Example: users, sponsor_tiers

Primary Key

Laravel provides the $table->id() function that automatically creates a primary key for the table that is unsigned integer and auto-incrementing. If you have a very good reason to use instead some sort of string consult first @v-stamenova or @TimKardol.

Attributes/Properties/Columns

The columns should be snake_case (undescore to separate words), lower case and should be in singular form.

Example: title, company_description

Foreign Key

Foreign keys should be the model name they refer to (singular), with '_id' appended to it (assuming the PK in the other table is 'id').

Example: user_id, sponsor_tier_id

Simple variables

Normal variables should be in camelCase (with the first character lower case), no spacing between words.

Example: $users, $bars

Methods (in Models, Controllers)

All methods should be in camelCase (with the first character lower case), no spacing between words.

Example: getUsers(), generateTimeslots(), index()

Resource Controller methods

If the controller is responsible for normal CRUD resource operations

VERB URI TYPICAL METHOD NAME ROUTE NAME
GET /photos index() photos.index
GET /photos/create create() photos.create
POST /photos store() photos.store
GET /photos/{photo} show() photos.show
GET /photos/{photo}/edit edit() photos.edit
PUT/PATCH /photos/{photo} update() photos.update
DELETE /photos/{photo} destroy() photos.destroy

Relationships

  • hasOne or belongsTo Relationship - like the naming of a normal method

Example: author(), user(), sponsorTier()

  • hasMany, belongsToMany, hasManyThrough - like the naming of a normal method but make sure it's in plural

Example: posts(), userInvitations()

Polymorphic relationships

[TBD]

Blade files

All files should be in kebab-case (only lowercase letters with dash between word), matching their related controllers.

Example: index() of ArticleController should return the view from articles/index.blade.php

If something is missing you can refer to this article and the big table in it.