Thoughts on code reviews

Developing software can get expensive when bugs are found. The cost of fixing a bug will vary depending on when the bug is found in the SDLC. Early on in the development of code, it is a minimal cost. Should the bug be found after the code has been deployed into production after a couple of months the cost is now high.

So if code reviews are part of the SDLC we can have due diligence that will minimize the risk of rogue code getting into the production environment. As a developer would you rather fix existing code or have the challenge of writing new.

With that in mind here are some of my thoughts about code reviews.

Triage first look

1. The naming of classes method variables. There should be a standard for naming. For example, when naming Classes and Methods use Pascal case. With variables use Camel Case.

For example:

Class: Member

Method: GetName

Variable: firstName


Names should also be meaningful.

2. Does project compile with no errors or warnings? Is it possible to download the code from source control and compile the solution without errors or warnings?

3. Are methods no longer than 40 lines. Greater than 40 lines and it can become difficult to read and understand.

4. Is the code readable, are there comments? Are agreed standards being used. As you read the code is it obvious as to what it is doing. Have this mentality. In 6 months’ time, if a mad crazed programmer was having to make a modification to the code I am writing would they be coming after me to stab me in the back?

5. Is there code reuse. Is it possible to reuse the code?

6. Are objects closed? If the code opens a database connection, is that connection closed when it is no longer needed.

7. Is there unreachable code?

8. One entry point, one exit point.

9. Is there exception handling. Does the code handle exceptions gracefully? Is there sufficient information captured so a developer can investigate. For a user do they see a meaning full error message? Is it possible to continue?


1. Is there trace/logging? When the code is out in production we do not have the luxury of setting breakpoints and looking a the value of an object. Logging events in code will be invaluable to understand what is happening in production.

2. Are there unit tests and do they pass? Unit tests are a great way to quickly identify if code is performing as expected.

3. When the code is run for given input is the output the expected value? This includes exceptions and fail states?

4. Is there input validation? Stop a user entering data that will cause code to fail. Check for legal input, this is easier to check that all the inputs that are not allowed.

Long term

1. Demonstrate code. When you get a chance demonstrate code to colleagues and ask for feedback.

2. Webinars. Many companies and individuals are creating videos to explain how to code. This can be a free and easy way to learn new techniques.

3. Training. Take advantage of training. This will expose you to different ideas. Sometimes taking a class in a language that is new can introduce new ideas for solving problems.

4. Read articles, blogs etc. By reading how other people have solved problems and can implement these ideas into our own code.

5. Talk to colleagues. No one person knows everything. Talk to colleagues about how they would solve a problem. Maybe they have already solved the problem or something similar.

This is by no means a comprehensive list and it is written from the perspective of someone who is coding in the Microsoft stack. The code review should be a living process. Yes, there will be times when something gets out into the wild.

Getting back to it

When I purchased the domain it was my intention to post on a regular basis about all things IT than interested me. As anyone can see from the dates of the posts there hasn’t been much activity. Life happens. My job has changed. I have gone from a development manager to a lead developer to a service delivery manager. I have also gone back to school and I’m over half way through an MBA program.


I have been active on twitter with @codingwith. My posts there have changed. Today I am tweeting about leadership, inspirational quotes and agile.


I am also reading more articles about the benefits blogging. For me, I believe it will help with creating clarity with my thoughts and help me to learn more about technology. I hope that I will see a reward in creating content, hopefully in my professional life where I have a mentor and coach role. I hope that this journey will allow me to experiment and discover new things. I hope that I will grow.


So it is today. I still have an interest in coding. I have an interest in building things that provide value. In my head are thousands of ideas swirling around. I want to get them out. So here goes, IT is time to get back. What can be expected? Well, I don’t like to set hard expectations. That is a recipe for failure. Things change. So, for now, my preferred outcome will be to post regularly, well, at least once a month while I am completing my MBA. I have a month to research and write about a topic I am interested in. If I post more than that then that is a bonus.


Let’s see where this goes. It’s time to get back to IT.


Github Quick Start

When I first started to use git I was using Bitbucket as my remote repository. As a tool for committing code and keeping local and remote repositories in sync I used SourceTree. While there is nothing wrong with this set up I have noticed that Github appeared to be the remote repository of choice on web articles I was reading. So I decided to give it a try. Here is my quick start guide.

1. Create Github account

2. Install GitHub for Windows on computer

3. Create a repository, quick-start, on Github


5. Copy the https link. Make a note of it.


6. Open GitHub for Windows.


6. Create a new repository.


7.  Add file to project folder, e.g. pommy.txt


8. From Git for Windows open a command shell


9. Check the status of the repository


10. Add the file to the local repository.


11. Check the status of the repository again.


12. Commit the change to the local repository.


13. Check the status of the repository again.


2. Create a remote reference to the Github repository


13. Check to see that remote has been added


14. Sync the remote repository with the local repository.


15. Push changes in the local repository to the remote repository.


16. View the github repository


So there you have it a Github for Windows quick start.  There is so much that can be accomplished with git. This just scratches the surface and I hope it is a useful stepping stone.

How to use moment.js

With recent work formatting of dates has been an important feature. From my reading around the bloggersphere I came across a JavaScript library that I have found to be useful – moment.js.

To start using moment.js download the library from

Create a html page and add a reference to the library.

<script src="scripts/moment.js" type="text/javascript"></script>

In the body of the page add content to display a time.

        <h2>Basic moment.js demonstration</h2>
        <input type="button" value="Get Date" onclick="getDate()" /><br />
        <span id="demoSpan"></span>

Next in the header add a JavaScript function to get the date from the moment.js library and display it.

        function getDate() {
            var theDate = moment().format("MM/DD/YYYY hh:mm:ss a");;

            var mySpan = document.getElementById("demoSpan");

            mySpan.innerHTML = "The date is " + theDate;


Note that initiating a date using moment() returns a timestamp and it can be formatted using the format function.

Putting this altogether creates a web page that


This is a basic introduction to the moment.js library. The library is extensive allowing manipulation, customization, parsing and more. The documentation is comprehensive and can be found at


You can down load this demo at Github.

Addendum 8/19/2014
Have uploaded a second file to the project that has more moment.js functionality


One of my favorite lines from a movie is from The Pirates of the Caribbean

the code is more what you’d call “guidelines” than actual rules

As I progress in my career I find myself in positions where I am leading, coaching and mentoring colleagues. A direction needs to be set. Whatever coding language is being used has it own syntax, libraries and best practices. Underneath there is the logic of if then else, switch statements, exception handling etc.

However there is a set of rules, well guidelines, that is a layer above the language that applies.  So as I’m designing, thinking and coding and talking about coding, not always done in that order, I recall the words that I saw written on a white board once

1. Make it Run

2. Make it Right

3. Make it Fast

Something clicked.  These three lines resonated with me. Since then I have promoted these ideas.

Rule 1 – Make it run:

When we talk to our business partners there is a vague idea about what they really want our software to do. This is the time to take the bull by the horns and write some code. Get something in front of the project sponsors. Show them something. It doesn’t have to be perfect. Ask questions. Is this what they wanted? Would it another approach be better?

  Rule 2 – Make it Right

So now you project sponsors have seen something. Adjustments have been made. Take the code and create what they actually want.

Rule 3 – Make it Fast

Your code now does exactly what your project sponsors want. Now is the time to make it fast. It is time to refactor. Eliminate the bottle necks. For example who wants to wait 5 seconds for a web page to load.

Now I thought that was it. However over time I’ve added 2 more rules.

Rule 4 –  Make IT simple

This was added to my list when I was discussing a design and system requirements with a business analysis . The business had all of these grand ideas, screens packed with data and functionality that may or may not actually be useful.. Sure with the right resources, time, money and manpower anything is possible. I pushed back, asking what the minimum product would actually work, keeping it simple. Also in the back of my mind, in the not too distant future, someone, and that could probably be you, will have to maintain the code. Fixing a bug, or adding functionality. There is a cost to this. Keeping the design simple helps those following you to understand what the thinking behind the design is. It allows them to easily make changes and not guess.

Rule 5 – Convention rather than configuration

Now I thought I was done but recently I have been writing some JavaScript code and unfortunately the files are getting large. This is when rule 5 was added.

I was writing similar functionality for different web pages.  Rather than write code specifically for the each page I decided to use the Ruby on Rails manta of convention rather than configuration. No more deciding whether to do this or that. Each business function treated in the same way. Easy to code and easy to debug.

So there you have it my 5 rules, sorry guidelines, for development.

1.Make it Run

2. Make it Right

3. Make it Fast

4. Make it Simple

5. Convention rather than configuration

As an after thought, add one more

Make IT fun.

Hello world!

So having create the website Coding with An Accent, my thoughts turned to what should the first post be about. Out of the box the first post is Hello World, so with my thought pattern why not say Hello to the World.

This past weekend I was talking to a couple of Computer Science College students. It turns out that they are learning Python. Not a language I was expecting. When I asked why both responded with because it’s easy. There was I expecting something like C# or Java.

My curiosity peaked. Was Python a language in demand? A quick trip to the Tiobe and I saw that Python for April 2014 was ranked number 8 and was at that rank back in 2013.

With this in mind here is my Python Hello World tutorial.

  1. Go to and download the latest stable version of Python.
  2. Install
  3. Open the Python Shell
  4. At the prompt enter print(“Hello World”) and press Enter.


There you have it. My first post. That was easy.