# The Gazelle's Coding Style Guide

Welcome to our style guide! This is where we outline the principles we try and stick to while writing code to make our own and future developer's lives easier.

# The Gazelle's Programming Style Guide

Welcome to our style guide! This is where we outline the principles we try and stick to while writing code to make our own and future developer's lives easier.

To first give you a bit of context, what drives many of the decisions made in this guide is the environment this software engineering project lives in. It is a project that will change hands many times, often between hands that do not have a lot of experience, and we will continuously be onboarding new developers that can have as little experience as only having completed Intro to Computer Science. This is a big challenge, and that is why in this guide we try to outline some best practices that we think will make it easier for less experienced developers to write high quality code as soon as possible. This also means that we are setting some pretty strict guidelines some times to make it easier to code with consistency and to take away some choices or worries from the developer. It is kind of treated like an open source project. We have also tried to be aware of not adding too many dependencies to our project that new developers need to learn, as we know that just getting into web development is something of a steep learning curve already. Every dependency we've added we've estimated (or at least hoped) that the ease it gives in terms of developer experience outweighs the extra learning curve it adds.

## The simple things that are actually so important

There are many things that developers new to Software Engineering can be surprised at that we take pretty seriously, and we can seem a bit pedantic, but software engineering is in big part about making code readable and maintainable so that someone else (or yourself after being away from your code for a few weeks or months) could come in and easily take over what you were working on.

### Variable Names
Writing good variable names is important, it is also very hard actually, but when done right it can make code delightfully easy to read. Here are some short articles that talk about variable naming we would recommend you to read at least some of. Don't necessarily take everything they say as facts, it is completely okay to agree with some of their preferences, but try to take away the idea of using variable names to document your code well, and to avoid making bad mistakes like naming your variables `var1`, or `i`, `j`, `k`, `a`, `b`, `c`. The resources are as follows: [A seemingly good guide to variable naming](https://a-nickels-worth.blogspot.com/2016/04/a-guide-to-naming-variables.html), [An also decent looking guide to variable naming](http://wiki.c2.com/?GoodVariableNames), [An interesting small case study on variable naming](https://m.signalvnoise.com/hunting-for-great-names-in-programming-16f624c8fc03).

Write the first part of the style guide
Write the first part of the style guide