Showing posts with label Error. Show all posts
Showing posts with label Error. 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

Thursday, September 25, 2014

Confusing Errors for a Confusing Feature? I disagree.

I follow Eric Lippert's blog "Fabulous adventures in coding" and his post today (Confusing errors for a confusing feature, part one) talks about a "confusing feature" and it's "confusing errors" of which I disagree.

I don't think that these errors are confusing at all, let me give you a little background of the issue before we begin.

Eric speaks about a feature in C# that requires unique meaning of variables throughout a block of code, something that means that you can't create a variable with the same name twice in the same block of code(scope), and you can't create a variable of the same name in a child scope either because it would make the variable ambiguous.

Eric says that he has a love/hate relationship with this feature, it keeps him from coding bugs into his applications occasionally.

What Eric doesn't like about this is the error that occurs when you try to declare a variable twice in the same scope.


 class C
 {
     static void M1()
     {
         int x2;
         {
             int x2;
         }
     }
 }


Gives an Error on the Inner x2:

error CS0136: A local variable named 'x2' cannot be declared in
this scope because it would give a different meaning to 'x2', which is
already used in a 'parent or current' scope to denote something else
Here is the direct quote from Eric after he says this,
It is no wonder I get mail from confused programmers when they see that crazy error message! 
What is crazy about that error?  It's in plain English, if you declare a second variable named the same as a previous variable it will overwrite the previous variable.  If this was something that the coder did intentionally then they should know that they don't need to declare the variable a second time and that they should just reassign the variable, on the other hand, if it was unintentional then it is probably bad naming on the part of the programmer.

I can see this being an issue when looking at some of the bad naming schemes that come across Code Review.  I know that the example code is just example code, but we come across code where the variables are listed nearly in alphabetical order

 class C  
 {  
     static void M1()  
     {  
         int a;  
         int b;  
         int c;  
         // ...  
         int x2;  
         {  
             int x2;  
         }  
     }  
 }  

and the meaning behind the variable is a lucky guess or only known to the original coder, kind of like Magic Numbers, but this is straying from the point of both posts.

The second thing (and third thing) that Eric says about this error is

And while we’re looking at this, why is 'parent or current' in quotes, and why doesn’t the compiler differentiate between whether it is the parent scope or the current scope?
In which I reply, the variable exists in both scopes, parent and child, meaning that where the error occurs the variable is in the current scope as well as in the parent scope, it already exists in scope.

This all points to naming, why should you need two variables named the exact same thing in the same scope?  You shouldn't it points flaws in the logic of the code you are trying to write.

RubberDuck from Code Review has from time to time pointed to one of Joel Spolsky's post titled "Making Wrong Code Look Wrong" and I think that trying to declare the same variable twice in the same scope falls under things that look wrong, because it is wrong and is a bad programming habit that C# didn't want invading from C++.

After those two statements Eric continues on to the next point and doesn't explain why doing this is a bad thing or how to keep from making this error in the future.

If we flip things around and try to declare the variable after one has been declared inside of a child scope the error message is a bit different.


 static void M3()  
 {  
     {  
         int x4;  
     }  
     int x4;  
 }  

Produces the following error:

error CS0136: A local variable named 'x4' cannot be declared in
this scope because it would give a different meaning to 'x4', which is
already used in a 'child' scope to denote something else
The compiler creates locations for all the variables ahead of time, scope is a means of use, or a map. If we have two cities right next to each other, with the same name in the same state, but in different counties it would be confusing regardless of which one is seen first, so why is this concept so confusing?

--------------------------------------------------------------------------------------------------------------------

I am sure that there is method to his madness in this post seeing that it is "part one" in the series of posts.

This post is more me thinking out loud about the whole thing and I should note also as a disclaimer that I didn't follow the directions and read the post he linked to before writing this post, for everyone's sake here is the link

Simple names are not so simple, part one

I look forward to the life long journey of learning, and the next post (whoever's it may be)

CodeReview User: Malachi