Showing posts with label Code Review. Show all posts
Showing posts with label Code Review. Show all posts

Wednesday, May 18, 2016

What causes bugs?

I think that developers have a good handle on the idea of bugs in the code, but the thing that I want to focus on is informing other people, who are not developers, how bugs form.   If we can help others to realize how bugs can form we can eliminate the amount of communication that is wasted trying to explain where the bug came from or why it happened all of a sudden. 

We have all had those changes because of business requirements that everyone that isn't a developer blames for creating bugs until the next major change.  What "everyone that isn't a developer" doesn't realize is that there are other variables that play a major factor in the creation of software bugs.  

As technology increasingly gets better, faster, more convenient, etc. the list of things that directly affect your code increases greatly and there is probably a formula for it that follows the Fibonacci sequence or some other fun algorithm like that.

What "everyone" might not know is that an increase in traffic to a site or server can cause things to change on the server, or cause an admin to make changes that will adversely affect your code.  You will not be notified of these changes, whether they be from traffic flow or an admin. In the ideal world, you would know the second a change happens that is going to affect your code,  you can plan for these things and you might even have alerts set up to tell you when traffic increases to your site or application, but if an admin makes a change to a server or a setting on the server, you may never know until something goes wrong with your site or application, and you will be banging your head against the wall trying to figure out why all of a sudden this bug appears out of nowhere.

Another thing that can really throw a monkey wrench into your code is something that was meant to keep bugs away or increase security,  an update.  I am not talking about the ones that "everyone" is thinking of, like the updates that you (or someone in your team/company) have made to another part of the application,  this is what "everyone" immediately thinks broke the application when something isn't working the way it previously did, this is the major update that "everyone" blames bugs on.  I am talking about updates to operating systems, IE, Edge, Cortana, text readers, PDF readers, other browsers, just about anything that needs updating that has to do with some part of your application.

Something else that "everyone" doesn't realize affects your application is the hardware that it is run on, not just your user interface but also the data server, the web server, the application server, the whatever server.  This likely won't cause issues with your application, but it is a possibility that it could cause an issue. Sometimes when we are creating a site and we use certain frameworks, those frameworks rely on a certain hardware structure or a combination of hardware structure and software settings on that piece of hardware, so when the combinations are changed, there is sometimes a chance of it causing a bug in your application.  Let's say that there isn't a lot of memory usage on the server, so someone says hey let's dial back the memory on this server and use it somewhere else (the things you can do with Virtual Machines), now something that doesn't run all the time gets run and you get an out of memory exception, it didn't happen before, why is it happening now?  now you have to do one of two things, rewrite the code to use less memory for this one process, or convince the controlling party that you need X amount of memory on call.

Knowing that bugs happen and how they happen, helps you to prepare for them to happen and how to communicate what happened to who needs to know this bug happened.

So, what causes bugs?

EVERYTHING

Tuesday, March 29, 2016

Null-safe Dereference in C# 6.0

Wow, how did I make this far and not know about this?

I love these, although I am still unsure as to how clean they make the code, or if they are going to make me a lazy coder by using them as opposed to what I have been doing.

I came across the null dereference because I was reviewing some code on my favorite code review site, CodeReview.  The code is being used to track downloaded applications in a set of applications that are being downloaded at one time.


if (lastRuntimeDetails != null) //at least one application was already downloaded
    if (lastRuntimeDetails.Ip != runtimeDetails.Ip || 
        lastRuntimeDetails.Port != runtimeDetails.Port)
            _requestExecutor?.Disconnect();

As I was reviewing this code there was an awkward if statement that was nested without brackets (yuck) so that was my first line of business.  The objects that were being compared were being created from a custom class called RuntimeDetails, the first object that is created is called lastRuntimeDetails and is being used to track the last application to make sure that the same application doesn't get downloaded a second time and to keep track of the IP Address and Port for each download. 

Anyway, at first I wanted to get rid of the outer if statement, it looked to me like it was extraneous, at first I was thinking that if the properties were null that they just wouldn't be equal to each other and give a false value to the condition statement.  

Comments were made about Null Reference Exceptions and a lot of thought went into how to do this, I kept thinking about the null properties, and that's when I found Null Dereference Operator, so I set up some tests to make sure that I had a good grasp on things

I created two classes, one to create objects and the other to return comparisons on the objects



public class Class1
{
    public string One { get; set; }
    public string Two { get; set; }
    public Class1()
    {
    }
}

public static class Class2
{
    public static bool returnBoolean(Class1 inputA, Class1 inputB)
    {
        return (inputA?.One == inputB.One);
    }
    

    public static bool checkOnNullProperty(Class1 inputA, Class1 inputB)
    {
        return (inputA.One == inputB.One);
    }

}

and then I eventually came up with the following tests


[TestMethod]
public void TestMethod1()
{
    var input1 = new Class1() { One = "string" };
    var input2 = new Class1() { Two = "string B Two" };
    var test = Class2.returnBoolean(input1, input2);
    Assert.IsFalse(test);
}

[TestMethod]
public void TestMethod2()
{
    var input1 = new Class1() { One = "string" };
    var input2 = new Class1() { One = "string B Two" };
    var test = Class2.returnBoolean(input1, input2);
    Assert.IsFalse(test);
}

[TestMethod]
public void TestMethod3()
{
    var input1 = new Class1() { One = "string" };
    var input2 = new Class1() { One = "string" };
    var test = Class2.returnBoolean(input1, input2);
    Assert.IsTrue(test);
}

[TestMethod]
[ExpectedException(typeof(NullReferenceException))]
public void TestMethod4()
{
    var input1 = new Class1() { One = "string" };
    Class1 input2 = null;
    var test = Class2.returnBoolean(input1, input2);
    Assert.IsFalse(test);
}

[TestMethod]
[ExpectedException(typeof(NullReferenceException))]
public void TestMethod5()
{
    var input1 = new Class1() { One = "string" };
    Class1 input2 = null;
    var test = Class2.checkOnNullProperty(input1, input2);
    Assert.IsFalse(test);
}

[TestMethod]
[ExpectedException(typeof(NullReferenceException))]
public void TestMethod6()
{
    Class1 input1 = null;
    Class1 input2 = new Class1() { One = "string" };
    var test = Class2.checkOnNullProperty(input1, input2);
    Assert.IsFalse(test);
}

Someone pointed out that if the object itself is null it will throw a Null Reference Exception, once they said that I looked at the code again and sure enough the container was created but no object was placed inside of it.


 RuntimeDetails lastRuntimeDetails = null;

So my initial thought of removing that outer if statement was wrong, but now I had new information that could be used to make sure that the Properties didn't throw a Null Reference Exception if the object was created but the property were null.

So here is the code that I suggested to replace the original code.


if (lastRuntimeDetails != null)
{
    if (lastRuntimeDetails?.Ip != runtimeDetails?.Ip ||
        lastRuntimeDetails?.Port != runtimeDetails?.Port)
    {
        _requestExecutor?.Disconnect();
    }
}

The object could be created with null properties now and then we could remove the outer if statement entirely.  I believe that the better solution is to set the properties on creation to some default and then when they are assigned they will be different from the default so the comparison could be made without the need to check for nulls thus removing the chance that future development would have to worry about checking for nulls.  or that the initial creation of the object, instead of being set the object to a null object, we create the object with null properties and then if the object's properties are null then they will give a false when compared to anything other than null (using the Dereference)

The Code Review Question in Question

and

My Answer

Wednesday, March 16, 2016

Code Stock

There has been a lot of talk around the office about Code Stock lately because the deadline for submitting talks is Friday at midnight (EDT).

Being a contractor it is not mandatory for me to submit a talk, but that doesn't mean that I can't submit a talk, so I have been throwing around the idea of writing something up.

When I started working here I didn't have very much (read as any) experience with AngularJS, I have worked with jQuery and AJAX a little bit and that has given me a little bit of a boost working with AngularJS, so I decided that I would talk about the process that I have been using in order to catch up to the rest of the developers here.

Check out Code Stock, sounds like it is going to be an awesome get together!

Thursday, May 21, 2015

Never stop Learning

I know a bit of C# and a myriad of other languages, but it results in jack of all trades master of none type of deal for me.  I don't like this at all, it restricts my confidence in my abilities and tries to stop me from treading ahead in projects.   I have pushed myself to start learning again, I chose ASP.NET MVC 5, which is very exciting, I can't wait to start creating websites with MVC.  The big thing that really gets me excited is figuring out a piece of the puzzle that has evaded me or intimidated me for the longest time.

I HAVE CONQUERED A NEW LAND!

I know about the concepts of MVC but never really put it to use because most of the projects that I work on are all legacy applications that were built 10+ years ago, so I couldn't even slip pieces of new technology into them without exerting a bit more time than my project managers would allow.

Now there is another new developer that is also interested in learning MVC, so he started a new project in MVC and everyone is forced to allow us the learning curve needed to make the site functional.

Figuring out the Syntax and how each piece of the puzzle fits together to make the system work is what makes this job satisfying and exciting all at the same time. 

Never stop learning.  Find a book or a good web series or a YouTube video and absorb all the knowledge that you can.

NEVER STOP LEARNING

Tuesday, April 28, 2015

Old Code, You Wrote

Do you ever go back to code you had written a long time ago and wonder who had written it and why they made it so messy?
I realized that I need to go through my documentation for some of my first projects here (or actually write the documentation).  While looking through the code I have seen things that I really want to change or improve, not that the code I had written before was bad, but the code could be better.  The only problem that I face in doing this is that then the code needs to be tested and compiled and pushed to production, and some of these projects have their feet in many places all at once.
I think that what I am going to do with this code (since I am short on time, most of the time) is to change some of the things that don't change the flow of logic.  I am talking about things like using blocks where before I didn't have them because I didn't know about them when I first wrote the code. 
The rest of the changes I think I might just put into the documentation of the code in a section labeled "Future Updates", or something of the like.  If the change isn't too ​big, but something that I don't want to change and not test for fear of breaking the code, I am going to write a little comment where I would make the change, something that would make complete sense to whoever looks at it, especially me.

​​​​​How do you document code?

Tuesday, September 30, 2014

Our Mission is Complete

The Mission that we chose to accept - Call of Duty - We're on a mission

Our terms of engagement were nothing less than Victory; we have succeeded and overcome the damage of the lull that preceded us into battle, we now stand victorious.




The Battle against the Zombies is a different story, let them not overcome us again, keep firing, keep stockpiling your ammunition, keep recruiting new warriors, keep engaging the Enemy!



Congratulations Code Review!

Code Review Graduation Meta Post

Monday, September 29, 2014

Code Review Graduation!

Come and Celebrate with us all at Code Review!


We have made the leap to full fledged site on the Stack Exchange Network!

If you have some code that you want someone to just take a quick peak at bring it by today, there are plenty of people there reviewing code on a daily basis, all the big languages are represented (and even some of the less popular as well)