Vision and dreams are the blueprints of soul and achievements.
-Mohammed Ahmed F

Debugging Tips

Folks,

From the Chief Administrative Officer's desk:-


"Earlier, debugging tips was in an exclusive page but now it has been given in a post so as not to limit exceed the page limits set by Blogger for each blog, this (http://bca-tnc.blogspot.com/) is one blog!


The actual debugging tips page which was published on 19 / 02 / 2014, received 75 pageviews + 1 comment as "Nice.. Tnx" by an Anonymous.


Hence, it is brought to the kind notice of the readers that henceforth, the page views generated for this post will be considered 75 + {pageViewed} under the account of Chief Administrative Officer which is nothing but the Administrator Console."





Here is your Debugging Tips:-




You are never too old to learn something stupid. You can go too slowly as well as too fast.

Don't avoid a topic after you have mastered everything in it. By facing more challenging ideas, it will help cement grasp of the basics.


1. Look at the example code:

Reading is usually about the words on the page, but learning to program is about Code. When you are first learning to program, you should make sure to look at and try to understand each and every example carefully and understand them. If you are unable to understand then try asking someone who has expertise in it, remember ‘Lesson repeat itself unless they are read”.

When I first learned to program, I would sometimes read the code examples before the text, and try to figure out how it worked. It doesn't always work, but it did force me to look at the example very carefully and at times it often helped make the concept clear.

2. Don't just read example codes but run them:

But when you are reading a programming book, it is easy to look at the sample code and say "I get it that makes sense". Of course, you might get it, but you might not get it, and you just don't know it. There is only one way to find out to do something with that code. Then type the sample code into a compiler, if you type it, instead of copying and pasting it, you will really force yourself to go through everything that is there. Typing the code will force you to pay attention to the details of the syntax of the language, things like those funny semicolons that seem to go after every line.

Then compile it and run it. Make sure it does what you think it does. Then change it. Software is the most easily changeable machinery available on the planet. You can experiment easily, try new things, see what happens, the changes will happen almost immediately. The easiest way to learn new language features is to take some code that works one way and change it to the other.


3. Write your own code as soon as possible:

Once you understand something about the language or even if you are still getting your head around it, start writing simple programs that use it.

Sometimes it is hard to find good ideas for what programs to write. That's OK; you don't have to come up with every idea at the beginning. You can find some programming challenges on this site.

You can also re-implement the examples from the book you are reading. Try to do so without looking back at the sample code; it won't be as easy as it seems. This technique can work especially well if you tweak the sample code. If you can't think of a small program to write, but you have in mind a larger program you want to implement, like a game, you could start building small pieces that you can later use for a game. Whether you use them later or not, you will get the same useful experience.


4. Learn to use a debugger:

The sooner you learn debugging, easier it will be to learn to program. The first step in doing so is to learn how to use a tool called a debugger which allows you to step through your code. A debugger will allow you to step line by line through a piece of code. It will let you see the values of variables and whether the code inside an "if" statement is executed.

A debugger can help you quickly answer questions about what your code is doing.

int main()
{
        int x;
        int y;
        if( x > 4 )  // What is the value of x here?
        {
                y = 5;   // Did this line of code execute?
        }
}

A final word about debuggers, the first time you learn about a debugger, it will take you longer to fix the problems with your code. After the tenth or so bug, it will really start to pay off.

And believe me, you will have way more than ten bugs in your programming career.
I often saw students unwilling to use a debugger.

These students really made life hard on themselves, taking ages to find very simple bugs. The sooner you learn to use a debugger, the sooner it will pay off.


5. Seek out more sources:

If you don't understand something, there's a good possibility the way it was explained just didn't click. First, look for alternative explanations. The internet and this blog are filled with information about programming, and some explanations work better for different people; you might need pictures, someone else might not. There are also lots of good books with detailed explanations.

But if that does not work, the easiest way to figure out where your misunderstanding lies is to ask someone else. But try to go beyond saying, "I don't understand. Please explain". You are likely to get a link back to the same text you did not understand. Instead, rephrase your understanding of the text in your words.

The more your question reveals about what you are thinking, the easier it will be for a knowledgeable expert to answer it.

Programmers sometimes have a reputation for being grumpy about answering questions, but I think the reason is that they want to make progress in a conversation, and that requires both sides to put in effort. If you ask a smart, detailed question that shows you are thinking, you will generally get good results.


Happy coding.


-Chief Administrative Officer.

Share this

Related Posts

Dear User,

Thank you for your comment. Hope you like this blog. Kindly share us on Social Media so others can be updated.

-Chief Administrative Officer.