Coding Best Practices

-When working on a solution to a problem for the first time, build an MVP (Minimal Viable Product) solution.

-Before you even touch your keyboard, Psorta-code (thinking in head when working by yourself or talking to your pair about what you think will work) then Pseudocode (Write down how your code is going to be implemented in pure words, meaning not actually coding language)

-When working on complex problems, such as forming algorithms, break down the problem into sections.

-An error message on your console is yourt friend, but when your code spits out unexpected values (assuming that you have worked out your logic), the Chrome Developer Tools is going to be your new best friend.

-When debugging, DONT BE SUPERSTITIOUS, be deliberate, form a theory then test the theory. Don’t just move things around or edit things without thinking it through, you wrote that piece of code there for a reason.

-Develop your workflow (Such as committing your work through git periodically)

-Get used to using the keyboard shortcuts on your text editor. It doesn’t matter if you’re using Sublime Text, Vim, Atom, Emacs, or Notepad++. If you’re not efficient with it, you are unnecessarily wasting your time, so don’t let other people convince you about which text editor is the best for you. Remember, Time >= $$$.

-To learn about OSX, Alfred, Sublime, Chrome, Bash shortcuts, checkout Josh Wyatt’s Github Repository https://github.com/joshwyatt/keyboard_shortcuts

-Encapsulation/Isolation/Modularity: Loose coupling comes with writing code with high modularity

-Encapsulation: a mechanism for wrapping the data (variables) and code acting on the data (methods) together as a single unit. (www.tutorialspoint.com/java/java_encapsulation.htm)

-Modularity refers to the dividing of an application into smaller modules. Such as having a library in a different file than the rest of your code.

-Loose coupling: you do not want your code to depend on others’ code

-Thin interface: writing a function in a way that in only takes in a handful of parameters.

-Intuitive abstractions: such as “well-written” function and variable names (self-documenting code) will save you a ton of time from having to go through your code and figuring out which is what. more readable and understandable.

-Input all dependencies: Avoid global or closure variables (Unless you know exactly what you are doing and intentionally want to taint a global variable)

-Similar to what I stated above, ideally, you don’t want to have side effects on things such as the input, global or closure variables.

-After you have a finished an MVP with no existing edge cases, style your code into shorter/ fewer/ clear lines. Basically cleaning up after yourself.

-DRY (Don’t repeat yourself) vs WET (We Enjoy Typing). WET is a joke among programmers. The third time you rewrite or copy and paste your code for a different function implementation, you are just showing off your inefficiency.

-“Always be humble and be ready to learn. This is a rapidly advancing field, if you start to think that you know everything, you’ll fall behind everyone else in no time.” (Laurie Voss CTO at NPM http://sel.do)