EngineeringWiki
  • Introduction
  • Top level Overview of the application
  • FAQs
  • Back End
    • Agent Pipeline
    • Mention Pipeline
    • Profile Pipeline
    • Errors
    • Overview of the Mention/Profile/Cluster Process
    • Adding a New Service
    • Activity and Status Tracking
  • Setup
    • Overview
    • How to Setup Your Local Machine
    • Setup - Cloud Machine
    • Infrastructure
    • Docker
    • Bash Commands
    • Setting up front end in Ubuntu 16.04 desktop
  • Gems/Libraries
    • Bax
    • Creating fixtures for Unit Tests
    • Audienti-Retriever
    • Scour
    • Haystack
    • Audienti-Indexer
    • Audienti-Api
    • Handler
    • Blackbook
    • Allusion
  • Code
    • Multi-step Modal Wizard
    • Structure
    • Audienti DataTables
    • Javascript
      • Passing Props From Root
      • Looping in JS
      • Binding Actions to App
      • CSSTransitionGroup
      • Code Best Practices
      • Reducer Updating an Array with Item in Middle
      • Organizing Javascript
      • Filter Array by Id
    • Design Language
  • Working
    • PostgresSQL
    • S3
    • Terminology
    • Interview Tests
    • Application Descriptions
    • Best Practices
      • Code Organization
      • Code Documentation (using Yard)
      • Git Workflow
      • Tasks and Queues
      • Working in Backend
    • Profiles & Enrichment
      • Profile ID Rules
  • Management
    • API Management
    • Bastion
    • Splash Proxy
    • Rancher
      • OpenVPN Server
      • Traefik Reverse Proxy
  • Teams & Interviews
    • Interview Questions
  • Culture
    • What Makes a World Class Engineer
  • Situational Statuses
    • 2017-11-03
    • 2018-01-09
  • Operations
Powered by GitBook
On this page
  1. Working
  2. Best Practices

Code Documentation (using Yard)

PreviousCode OrganizationNextGit Workflow

Last updated 7 years ago

Code documentation is a CRITICAL aspect of writing professional grade code. In all cases, we must strive for code that is simple, clean, organized, consistent, DRY, and tested.

To accomplish this, there are a few standards we are employing to make this happen:

In Code

  • We use YARD to document our code when we are writing the code. This means that the class should have a description on the top of it that defines what the class does. What is its goal, and how is this class used. In addition, each method should have a description for what this code does as well. At a minimum, unless the method does NOTHING (which it should be removed) at least a 1 line description should be there, plus a definition of what a return should look like.

  • We use Swagger, automatically generated from our RSPEC tests, for documenting our API. If you are working on the API, you MUST define your API controller's behavior using the swagger helpers. These provide get/post and response code handling that lets us create swagger documentation for the API.

Example of a well documented controller

Example of an RSpec testing a controller, using the Swagger helpers that define swagger documentation