Simple web dev. debugging methods

The geek forum. PHP, Perl, HTML, hardware questions etc.. it's all in here. Got a techie question? We'll sort you out. Ask your questions or post a link to your own site here!

Simple web dev. debugging methods

Postby Sammy Boy » Thu Jun 05, 2014 5:50 am

Was stuck on some code at work today so thought to share some simple debugging methods I use for web development (applies to Javascript and CSS, but the logic can be applied to pretty much any computer language).

1. Test whether code enters certain loops / conditionals by placing 'alert' statements within.

Example:

if (answer == 'yes')
{
alert('answer is yes');
.......
}

If the alert does not appear it means somehow the code has failed to enter that conditional statement, which means it's a hint to check what the value of 'answer' is.

2. Comment / un-comment code to look for statements that break the rest of your code.

I was pretty sure my syntax was correct, but when I ran my code in Chrome, it kept throwing me an undefined error.

I then commented out the conditional that evaluated the variable, and the code ran fine. That made me realise Google Chrome is not knowing about the variable's value.

After reading around I found that Chrome has a modalDialog bug in that window.returnValue isn't passed back to the calling function. It also looks this bug isn't getting fixed anytime soon (https://code.google.com/p/chromium/issu ... ?id=324392).

So I ended up writing a workaround for it (ditched modalDialog and went for the JS confirm option - cheap, but it does the job).

3. If the issue is with display / alignment of HTML elements on a web page, try to give all the elements an outline, like so:

<style>
.testDiv { outline: #f00 solid 1px; }
</style>

then apply like so:

<body>
.....
<div class="testDiv">Some text here</div>
.....
</body>

The thing about outlines are that they do not take up extra space (unlike the CSS border property), so you can apply them to check where the elements start and end without being concerned that the outline is responsible for the breaking (since there is no width getting pushing them out by the extra defined width).

4. Last but probably one of the most effective non-tech debugging method - is to go get some fresh air, wash your face, or drink some water / juice. It can do wonders for you. :)
User avatar
Sammy Boy
 
Posts: 1410
Joined: Wed May 25, 2005 7:04 am
Location: Autobase, Cybertron

Re: Simple web dev. debugging methods

Postby Dante » Fri Jun 06, 2014 11:42 pm

LOL, wow, this brings back memories. These days, though, doing this would cause me to tear my hair out. Here are a few ways that will make your coding life a bit easier.

For most of these... start by downloading Firefox and it's killer plugin, Firebug. Then, after it's installed, go to your webpage and click on the little beetle in the upper right hand corner of your browser. Firebug should start up in console mode at the bottom of your page.

1) If you ever want to test a variable at any point your application, just use in that section of the js code:

Code: Select all
console.log('hello world!');


But, of course, replace the string with the variable or other code you want to test. It doesn't necessarily even have to be a string, JavaScript has a tendency of happily coercing variables into more readable formats for easy debugging.

Also, if your code happens to hit an error, it will more than likely show up here so that you can readily fix the problem. It makes your debugging life so much easier!

2. Now click on the script portion of Firebug. This is the awesome part. The main area here, is a text area filled with code, by clicking to the left of the numbers in this area, you can set break points, just like you could in an IDE. If you right-click on it, you can even add conditional break-points. Next to the all button at the top, you can flip between various JS files and on the far right, you can add watch commands. Once you've added these in, you'll probably want to refresh the page if you want to run through any scripts that occur at start-up.

3. What about the alignment issues? Firebug has you covered there as well! Just click on html and your file as it presently is loaded on screen should appear in nested format. If you dig into this file, to the area you're interested in, you'll notice that on-screen, portions of your webpage will start to light up, granting you insights as to how each section takes up space in your layout. Also, as you click on each element in the layout, you'll notice that a css screen pops up on the right, where you can change (in real-time) the css styling of the element, allowing you to rapidly test solutions for your problems! It will also tell you where your object inherits that property, which tells you where to change it in your css file.

(This section is also useful for 'discovering' ids and classes that other people's code add in dynamically when implemented as the html will change in real time to changes that occur on the page!)

4. Also - Stack Overflow. Stack Overflow is a developers best friend.

5. Finally, there is this amazing framework (that I sadly, rarely use) called Jasmine:

http://jasmine.github.io/2.0/introduction.html

Jasmine is a javascript framework that you can use for Javascript Test Driven Development (TDD). In this development style, you literally come up with a behavior that you want to see first (resulting in a failed test) then create a code function that solves that problem when tested (resulting in a passed test). Thus, it is called red/green development. Developing in this style tends to be great for results that you can easily test, such as string manipulation, numbers - things that you could readily write tests for. I've personally gotten a bad taste from it, however, when it's applied to UI development, although that can actually be done.

Overall, though, if you can write your code so that it passes all your tests and your tests describe your behaviors, you not only will have code that works, but also code that you can easily refactor, especially as you get into more advanced toys, like CoffeeScript, HAML, SASS, LESS, Bourbon (the api not the alchohol) and what not. You'll also sleep better at night, knowing that if anything ever breaks, you can just jump to your tests and find out which tests fail, so that you know instantly where the code problem arose.

PS - While note really part of debugging, another note is that you can debug what's causing lag on your page load in the Page Speed Section (may or may not require another plugin for that, I can't remember). Doing so will tell you all the different ways in which you can speed up your user experience.
User avatar
Dante
 
Posts: 1323
Joined: Thu Mar 04, 2004 8:24 pm
Location: Where-ever it is, it sure is hot!

Re: Simple web dev. debugging methods

Postby Sammy Boy » Sun Jun 08, 2014 6:04 am

Hey Dante, thanks for the tip about Jasmine! I haven't kept up to date with a lot of the web development stuff as I don't get much opportunity to write code these days.

I know about Firebug and try to use it whenever possible, but because the modalDialog bug was specific to Chrome, it wasn't a problem when I ran it in Firefox.

The other issue is that unfortunately I still have to develop for the IE8 platform - hence a lot of the problems is not really noticeable in Firefox, because CSS works much better there than in IE8. Don't ask why I have to code for IE8 for the clients, that particular decision is above my pay grade. LOL :)
User avatar
Sammy Boy
 
Posts: 1410
Joined: Wed May 25, 2005 7:04 am
Location: Autobase, Cybertron


Return to Computing and Links

Who is online

Users browsing this forum: No registered users and 89 guests