Debugging notes - Understanding the gap between input data, system definition and logic

When you start writing to code, it shows how much you know when you try to perform things logically. Debugging is figuring out what does not work.

I have been working on projects as part of Level Zero of NeogCamp which is based on HTML, CSS and Javascript. Now Javascript opens a whole new world on how you want to play around with the web page. I ran through lot of errors and I share some of the lessons I learnt through debugging.

--

When we are declaring an input via let, var or const we are not assigning any data type to it.

When we declare an input element in html and put text as the input, what it basically means is that data type of string or a sequence of characters will be taken in the system. Now that means a single character, a word, a paragraph, a number, a negative number or anything else entered will be by default stored as a string. This is a system definition of input type text.

Now if we expect our logic for our expected output to work on numbers only, we now need to convert that string into a number. But what if the user accidentally, mistakenly or knowingly types a character? Then we need to add additional functions or statements to distinguish the entered data as a character or a number and depending on that we can proceed with our next logic.

If it’s a character, we do something.

If it’s a number we do something.

The problem with broad definition of text is that what we intend to do is what will not occur. We have to fill the gap between input taken, system definitions of functions and statements and our logic.

When we design a logic, we should do unit testing or timely testing to see if the functions or statements are executing properly.

Otherwise we may waste our time writing elaborate functions or statements thinking something only to realize that at some point, the system is not interpreting it as we want to. An example I want to quote is, I was trying to understand if the string entered is a number or not. For this I used the parseInt function which basically turns a number entered as string to a number but as a number data type ( it does more, read it here; but in this case of non decimal number input it works). This makes it easy to perform numerical functions that may be essential for our output.

But a catch is if we enter a character or word in parseInt it returns a NaN, which is basically read as Not a Number. NaN comparisons are tricky in evaluation or may not return anything. You need additional knowledge to make things work in that case. So I had to use the isNaN function to make this happen. Read more about it here.

Understanding how the data is “declared as input” and how the data is "entered as input" and how the data is “understood as input” is very important. Our logic is defined understanding that the inputted data type by user is the same as the declared input type by the creator. But if it is not, then our program may not perform as expected. We need additional statements to take care of inputted data by user so that the functions and the statements perform logically as the creator wants it to. It is also important that during the course of processing data from one function to another or from one statement to another, the result that may be passed on, may be incorrect as per our need but logically may be correct in execution. We may intend 'x' to happen but 'y' happens and the program completes without any errors but we don’t get any desired output.

Understanding how data is working at each level, understanding the results at each statement gives us a lot of clarity on what to do to get the next logical statement right. In order to reach the output we have to find a way to fix what’s not working and that is where understanding of data and data types is very important. What we think and what is thought of by the system should be the same. Otherwise we need to find a way around to make the logic work as per the system definitions. These system definitions are limited to perform a set of things only. Understanding the limitations allows us to think how to proceed with the next logic.

Some additional reading I did during this article: See this example and the answer about negative numbers