What I look for when I do a code review:

__FOCUS__
- Methods should do one thing and do that thing well.
- Name methods and variables well.  This is simple to do and most developers mess this up.  A name is not a big deal until
someone in a hurry needs to get context on a problem fast.  For example: handler(), process(), flag, temp, all will only hurt.
- Methods that group operations together and run them in a specific order should be named appropriately.
- Each line in a method should do 1 thing.
 - Ternary operations are OK if they are simple and pass the glance test. If someone has to look at the code for more than 1 second to figure out what is going on it should be broken up right away.
 - Keep in mind in prod when a stack trace generates a line and it lands on ternary that is two different cases that will have to be considered. Code should be written such that a glance can yeild high amount of information regarding the issue.
 - An if statement ought to be accompanied by an else or an explicit return, if for nothing else but for testing purposes.

__Simplicity__
- Fight hard to keep the code simple.
- Fight any and all attempts to make the code more complex in the name of "performance".  Rarely does the trade off between readability and performance pay off.
- Avoid for loops or while loops to iterate over collections. Use `each`, `map`, etc.
- Performance for the sake of performance is evil.  Do not trade readability over performance unless the gain is orders of magnitude AND monetizable.  Do not make useless things fast.
- In ruby you don't need Parans, but use them liberally when readability is enhanced.  Ex Large Math Equations that are mission critical.  Wrapped method calls, parans can help reveal the order of operations.
- Move complex boolean logic into methods with revealing names.  Something like `disabled?` is far better
  `((expired == true && end_date < Time.now) || access_revoked == true)`
- Avoid deep nesting.  3 levels is pushing it.

__HARDCODES__
- No magic numbers or strings
- Do not hardcode in values directly into production codebase.  This style of coding if fine while prototyping or debugging but not for production.

__DELETE WITHOUT MERCY__
- Remove all code that is unreachable
- Remove comments that help describe code, the code should be readable without comments
- Remove dead comments (yes this is a real thing)
- Remove commented out code
- Kill TODO comments, Comments regarding unfinished or broken code.  All that is noise.  Move into a tracking system or simply remove.

__COMMENTS__
- Long paragraphs in the code are a smell.
- Tech talk to be avoided in comments.  Do not use terms like "stack", "map" etc.  Communicate in terms of business process.
- Comments should describe INTENT.  Focus on what is to be achieved and NOT the code is doing.
- Comments should summarize (as simple as possible ) what the process is.
- OLD OUTDATED COMMENTS CAUSE MORE HARM THEN MISSING COMMENTS (Best of to avoid them or keep it super short).
- NO marker commments. `Not quiet done` (two years old) OR `This is a hack and needs to be fixed` .


__CONST__
- When comparing always put constants on the left side of the comparison

__return__
- Please try to limit returns to one per method/function
- Sometimes it makes use to have multiple returns it increases readablility.  But in long winding methods it is helpful
to limit it to one.

__Nils__
- Nils are a real pain.
- Solve using sensible defaults.
- Find of the root of the calculation and handle possible nils there and avoid nil checks at every level of the system.

__Divide by zero__
- Any and all denominators should be checked for 0 when using % or /

__GLOBALS__
- Should something really be Global.  Spend time thinking about this.  Using globals is addicitive, adding to the global scope should not be taken lightly.  A bunch of stuff always hanging around in memory is a bad call.

__Caching__
- Is always trickier than meets the eye.
- Solves one problem and can create another (possible deeper).
- Absolute and total dependence on cache can lead to vendor lockin and other vendor traps.
- Just be careful and test well.

__General__
- Check inputs before using them.  It is _Defensive/Paranoid_ for sensitive data for sure.
- Variable spans.  Keep the distance in lines between initializing a var and seeing it for the last close as possible.  The larger the span of lines the riskier it is that the var will be forgotten.
- __DRY__
- Work to keep all the code as unique as possible.  It is a smell if you have code that is similar or shares common patterns but it is not unique.  Attempt to remove duplicated patterns and move them into a method and keep everything as unique as possible.  Too many times this is the result of a large copy-pastes and one or two lines added or removed to get a feature built.  Look up OOP techniques to help with this.