Skip to content

SomeoddpilotInc/Someoddpilot-Coding-Style

Repository files navigation

Someoddpilot Coding Style

We have some common practices in our development workflow.

Some basic principals apply to all programming, regardless of language.

Some basic conventions apply across all languages.

All code should be source controlled.

Workflow

Languages

Templating

Templating principles

Package management

Package managers allows automation of the installation process of tools and libraries. This installation process can then be repeated easily as the code base is changed, pushed to other developers, and ultimately deployed.

Third party code should never be included in the source of a project and instead be managed via a package.

First party code should be abstracted into a package when feasible.

yarn

Use yarn to install Node.js modules. Yarn is a port of npm, so you should be familiar with npm.

Composer

Use Composer to install PHP modules.

Homebrew

Use Homebrew to install OS X command line packages.

Reference

Code Analysis

Linters

Code should always be linted by the appropriate linter. Sloppy code is dangerous code.

Reference

Similarities

PHPCPD

PHP projects should be run through PHP Copy Paste Detector.

Simian

Projects should be run through Simian to find lines of code that are similar. These lines should be refactored.

-excludes={*.sublime-workspace,node_modules,bower_components}
-includes={**/,}**/*.{js,php,scss,hbs}
-formatter=plain:simian.txt
-threshold=4

Reference

Tasks

All common tasks should be automated and configurable.

Grunt

Use Grunt to create tasks which can be run via the command line or by watching a set of files.

Reference

Testing

Unit Testing

Significan modules should always be unit tested. Unit tests provide a quickly repeatable way to automatically test functionality and prevent newer code from interfering with previous code.

Behavior Driven

Interactive modules should be tested with behavior driven tests to ensure that interactivity is functional in all environments through all stages of development.

Test Driven

Modules with complex, custom CRUD operations or calculations should be developed using test driven fundamentals.

Browser Testing

Functionality should be tested in latest versions of:

  • Safari
  • Chrome
  • Mozilla
  • iOS
  • Android
  • IE

Testing should occur in native, hardware environment, not emulated.

Reference

Kaizen

We’re constantly changing and improving how we get things done in the codebase. Often times that means this documentation falls behind our actual process. Please fork it and update it!

Additionally, if you can identify an area where we could better handle a process, bring the issue to the table and we figure out how to keep things running smoothly for everyone.

We have tons of books on programming. Talk to me and I'll find what you're looking for.

About

A general overview of our coding style here at Someoddpilot

Resources

Stars

Watchers

Forks

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •