Treatise on code review

• Code Review should default to approved, broken tests will stop the approval process
• If new code has no tests you can ask for a test
• Styling is optional.  If styling is important to you don't make a comment, make a template or choose a language that forces a certain style on checkin i.e. Go

Note that Go was designed this way to force new programmers to formalize their thoughts and is not considered a benefit unless you focus your organization like Google i.e. huge monorepo with thousands of people writing code and everyone comes and goes (people only last 1 - 2 years in a codebase maximum for the majority of employees), but the code remains.  I do not think this is a good approach to take with anyone who has coded for more than a few months.  Tests and end results are what successful programs are validated against not styling and compactness.  This raw truth is ever present in the systems we use I mean the ACH processing machines still run COBOL, astronomy modeling code is in FORTRAN and ATM machines are running Visual Basic forms.  They get the job done and that is what people value more than is this a functional method call with side effects, oh dear no.

Please note these are only my personal thoughts not an endorsement or ideology i.e. it is subject to change

This falls under my interpretation of Working Software in the Agile manifesto.

I don't really care about any styles.  I mean I have my own style preferences (but they are biased and most likely wrong and if someone shows me a new way I am open to changing how I write things because I want to learn and expand my level of understanding), but whoever uses the code last can style it however they want is my feeling (if I do this it's because I want to have all the usings outside namespaces for me to understand scope easier.  If you put them all inside I would approve your request as the person who last touches it is responsible for maintenance).  As long as tests pass and application continues to work is the judgement I am looking at results oriented, because you do not have test coverage that grants this level of security I will move it back.

To expand on this point of exploration which I  further think about how code and languages change over time.  If we also conform to a single format or language you don't explore or experiment with options that may give greater communication and inspiration i.e. if people still wrote 1995 Java code today others would have a hard time understanding it and also we wouldn't have the wonderful opportunity to write all our new JavaScript code (this is only partially a joke).

Thinking about it what is happening in JavaScript is a good example of how collaborative exploration and lack of guidelines can form a mass of original ideas and approaches that attracts and fleshes out ideas like:

• Is this possible?
• Why don't we do it that way?
• What if I did this?
• This seems off to me what if I presented text this way?  (this is a personal decision and not a logical one, but we as humans are not rational or logical even though we try at times)

This gives you some wonderful things like Tail call recursion optimization, Class objects to make TypeScript, Functional methodology to apply for set manipulation Filter, Map, Apply, etc

Other concepts that have sprung forth from people doing things outside the paradigms of the time are Waterfall to Agile, No tests to Unit/Integration Tests,