Or feel free the take the advice seriously. I'm relaying to you what I learned that helped me grasp OO design and after having to pound through 13 and 15 page if and case statements that were a license for fuck up and unmaintainable code and turn them into something useful and easily expanded.
Call a variable b. Or call it myWordIndex. One requires you to think for a least split second to understand what the variable's use it for, the other requires a little more typing but is painfully obvious.
Prefix your variables of different scope with an identifier so it is painfully obvious what each variable is scoped to or don't. I vote for painfully obvious. We have to think less to maintain our code and we will make less mistakes because of a liiiitle more time spent setting it up.
When you take something that is initially obscure and remove a level of obscurity with a small bit of effort, you naturally make code more self documenting and easier to understand. This is especially true when you have to look at at your code after 6 months or a year.
Make your code self descriptive and the time you spend will pay itself back in the time you DON'T have to spend figuring it out again when you have to maintain or debug it.
Or don't believe me and keep on making the same mistakes. I learned this by facing my old bad habits and seeing if it was worth it to spend the time to make my core more naturally understandable. It's paid back many many times over.
Don't use your brainpower trying to understand code that you wrote, use it to come up with the creative solutions and write clear, understandable, well structured code that is a breeze to debug and expand.
Cheers, - Alex On Jan 10, 2011, at 7:29 PM, Stockly, Ed wrote:
>>>>Never call a variable x. If x is your application's name, then call it myApp.
>>>>We now have the option of using descriptive variable names. Calling variables, i, j, or x is meaningless. Call the variable what it represents. I use the short, but effective prefix of "my" to indicate that it is a local.
Feel free to ignore the above advice.
I (and many others who post to this list) often use single character variables.
When I use them they always refer to an integer used in counting.
repeat with x from 1 to 100
I do limit myself to x,y,z (when counting items in nested lists): go to page z of spread x of document x.
a, b
and
i
>>>preface your globals with a g. This tells you instantly that it is a global. You don't have to think about it, you just know.
>>Like so:
>>gMonitorSize
>>pMonitorSize
This has come up numerous times on this list and there is not general agreement.
It’s generally pretty easy to track the differences between globals and locals in AppleScript.
Plus, those variable names ruin the english-like syntax, and make scripts less readable and understandable.
>>>>You only will become a better programmer when you learn to break these habits.
Not all good habits are created equal.
ES
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden
|