Wednesday, June 1, 2016

Format Your Code: Part II

In my last post, I brought up some guidelines and tips to help you (and others) to more easily understand your code.  In that previous post (click here in case you haven't read that one already), I discussed Collapsible Code Regions.  In this post, I'll discuss Indentation, Line Breaks, and Empty Spaces.

Indentation

Indentation can have a tremendous impact on how quickly you can look at code and understand what it’s doing.  Consider the differences between the two code blocks below:



While the color coding that iLogic gives you does help differentiate functions and conditional statements from other data, it’s much easier to review the code on the right and easily see where each case ends.  This is not only more appealing to the eye, it’s a time saver when looking at code, especially code that someone else wrote.  A couple of quick TABs is all that is needed or you can use the Increase Indent and Decrease Indent commands that are on the Rules Editor Editing toolbar.  Hint:  If you use the Editing toolbar, you can have your cursor anywhere in the line or you can select multiple lines and use the TAB key.


Line Breaks

Line Breaks are used when a single line will wrap past the right edge of the Rules Editor window and are another tool that is used to make your code easier to follow.  Line Breaks are created by a single space and then an underscore:  _.  Care should be taken to ensure the break is placed at a spot in the line that is easily understood.  The next line should be indented so that it’s easily recognized as a continuation of the preceding line.




Line breaks keep the reader from having to scroll to the right to read all of the code.

Empty spaces


Empty spaces are another easy way to organize your code.  They are simply a few carriage returns to put some empty space between blocks of code.  Empty spaces are a visual way of telling the reader “This bit of code has nothing to do with that last bit of code”.   It sounds simple and it is simple but it goes a long way to making your code easier to follow.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." ~ Brian W. Kernighan

Thanks,
Randy