https://handbook.gradientmetrics.com/product-team/coding/coding-standards/ Recent content in Coding Standards on Handbook Hugo -- gohugo.io https://handbook.gradientmetrics.com/product-team/coding/coding-standards/coding-principles/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/coding-standards/coding-principles/ Gradient Coders 1. Keep it simple & stupid Over-complicating code is the bane of all coding issues. In the words of Antoine de Saint-Exupery, “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” 2. Keep it DRY (Don’t Repeat Yourself) Whenever you copy and paste a piece of code - there is almost always an easier solution (e.g. write a function). https://handbook.gradientmetrics.com/product-team/coding/coding-standards/coding-hygiene/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/coding-standards/coding-hygiene/ Fewer models, fewer variables We do not filter results until the very end Use saved / intermediate results sparingly Keep track of observations Everything should be contributing to a deliverable Code formatting Fewer models, fewer variables One data frame for each unit of analysis. E.g. Customer Transaction Item One model for each considered dependent variable and features' set Use the model that performs and suits the best Leave only the model with the features' space that was finally used Use longer pipes to avoid partial data. https://handbook.gradientmetrics.com/product-team/coding/coding-standards/commenting-protocol/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/coding-standards/commenting-protocol/ This page shows you how we comment our code and what the general protocol is. Each assigned function needs to have properly documented parameters, a title, one line of description and at least one example. It should follow roxygen2 syntax, and should be written in markdown. See the below Conjoint function for a good example of an overly detailed function (as all our functions should be!) #' @import dplyr #' @importFrom aws. https://handbook.gradientmetrics.com/product-team/coding/coding-standards/naming-conventions/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/coding-standards/naming-conventions/ General Data Frames Constants Examples Other variables Examples Functions Examples This guide explains how we name our code variables at Gradient. This refers to every R script we will ever create. Read through this and adhere to our protocol to improve collaboration! If a script in a Pull Request does not adhere to these naming rules, link to this page and let the coder update the names. https://handbook.gradientmetrics.com/product-team/coding/coding-standards/file-saving-conventions/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/coding-standards/file-saving-conventions/ Project files in a Repository R Data R Objects Project files in a Repository Our projects all follow the same structure as explained in Coding at Gradient Never use any of the following Unicode characters in your file names: < (less than) > (greater than) : (colon) " (double quote) / (forward slash) \ (backslash) | (vertical bar or pipe) ? https://handbook.gradientmetrics.com/product-team/coding/coding-standards/our-standard-libraries/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/coding-standards/our-standard-libraries/ Preferred / go-to packages Other noteworthy packages As a team of coders — it’s very healthy and good practice to use the same set of libraries. This improves our ability to collaborate and the readability of our code. This document showcases the libraries that we picked out as a team, and should always be used over their alternatives if the same results can be achieved.