What Opens Must Close
<p>Quick detour - I want to let you in on a little secret: one of my best <b>02 Tips</b>. It's my favorite shortcut in the book and will help you manage the many <a href="/courses/video/8/65/Brackets.html">brackets</a> with which you work.</p> <p>In the programming field, we deal with many, many brackets. The use of brackets increases from time to time as we move further: it becomes very complicated to handle the code if we don't follow certain rules. The first rule is that an open bracket must always be closed. If we open a bracket and forget to close it then it will cause a problem, so we strongly recommend closing any bracket as soon as you open it. Mostly when we're dealing with bigger codes, if we don't close the bracket immediately after opening it, we may forget and it'll take a long time to find that a <a href="/courses/video/4/155/Error-1067-Implicit-Coercion.html">error</a> in the program. It only makes sense to abide by the rules and follow the instructions to ensure that there is no error with our brackets.</p> <p>At times even after all care and concentration, we may leave a bracket open. In this case, Flash will help you by giving a hint saying you did not close a bracket. We advise you to at least look at the hint even if you're confident about the code. One of the first things you need to realize is that error messages aren't a negative! They're actually there to help you figure out what you did wrong. Many <a href="/category/developer-basics">developers</a> - mainly new developers – will get "scared" of the error and not read it - as most of the time the error will be explicit enough to figure out what is wrong.</p> <p>After getting over the fear of the errors, you'll find error management tools such as Flash to be very advanced, detailed, and even user-friendly. The compiled application usually will return detailed errors in sufficient depth for the nature of the issue to be easily understood. Many times you'll need to know what area of your code you're in (all code is comprised of areas enclosed by brackets.) For that we have a great shortcut in this video: here is a technique through which we can avoid this error even before compiling it. (We can promise you one thing for sure: an ounce of error prevention is worth a dang ton of cure! Especially when the cure in this case means hunting through your code like searching for a needle in a haystack. Nothing like mixing a few metaphors, is there?) </p> <p><b>02 Tip</b>: If you click on code within brackets and hit command/control+space bar (or single quote,) the code <b>inside</b> the brackets is highlighted – not including the brackets. You'll see only the code highlighted: neither the opening nor closing brackets will be. If your code is properly indented, when you type a bracket, the next line should be one tab farther to the right and the closing bracket is directly under the first letter in that top line. Properly indented code looks like this (though we're using pseudo-code for now): </p> <p>if you have a hot date {</p> <p>you need to be well-dressed; </p> <p>if you have nothing to wear {</p> <p>better go shopping; </p> <p>take a shower: </p> <p>smell good; </p> <p>}</p> <p> }</p> <p>If you click on 'shopping' and press control/command+space bar or single-quote, highlighting begins to the right of the bracket following 'wear' and continues down just to the left of the one under 'good.' That final bracket should be at the end of an imaginary vertical line dropped from the 'I' in the 'if nothing to wear' line. If it'sn't and highlighting goes all the way to the left of that last bracket, – you've left out a bracket! You can test this by typing in the following small program: </p> <p>var inABar:Boolean = true; // get these variables by asking user</p> <p>var hotGuyApproaches:Boolean = true var lineGreat:Boolean;</p> <p>if (inABar) {</p> <p>if (hotGuyApproaches) {</p> <p>lineGreat=listenToLines();</p> <p>if (lineGreat) {</p> <p>trace("Straighten back, stick out boobs");</p> <p>trace("rattle ice in empty drink");</p> <p>} // end of lineGreat if</p> <p>else {</p> <p>trace("Turn back to dude");</p> <p>} // end of lineGood() bracket</p> <p>} // end of hotGuyApproaches bracket </p> <p>} // end of inABar bracket</p> <p>}</p> <p>public function listenToLines():Boolean {</p> <p>var goodLine:Boolean = true; // grab user input into Boolean variable goodLine and return it</p> <p>return goodLine; </p> <p>}</p> <p>You don't need to type in those comments... but you'll see how useful comments are, if you do! </p> <p>First, make sure the program runs correctly (outputs "straighten..." and "rattle...") If it does, now is the time for some real fun! </p> <p>Delete the <b>"// end of lineGreat if"</b> bracket. Save & run. Hmmmmmm! Click on "boobs." Press command/control + spacebar or quote. What do you see? Replace the bracket: click in the same place, press those keys. What do you see NOW? </p> <p>Try this again several times by deleting one bracket, repeating those steps until your eye becomes familiar with the odd look of a missing bracket. Worth the effort, believe us! </p> <p> In addition to finding a missing bracket, we can also use this technique for understanding the program. Most new programmers get confused initially when they see so many <a href="/courses/video/8/65/Brackets.html">brackets</a> in code: this shortcut is a great way to focus your attention at small blocks as you expand your decrypt smaller areas of the application.</p>