The first tip I wanted to share, is the “cd()” command. This allows you to change your scope of the console. I wish I would have found this years ago! It may seem trivial, but when coding with IFRAMES it’s always frustrating to prepend your code with “frames.” all of the time.
Why? Oh, because you forgot you’re in the wrong scope. You could always hit [up], [home], and then prepend the line with “frames” – which is what I have always done in the past.
This is fine for a couple one liners but when you’re using Developer Tools to test/write various functions, it’s rather tedious. Instead, you can change the scope of the console by using the “cd(frames)” command.
Logging to the Console
I’ve seen a lot of developers riddle their code with alert boxes to track down issues. While this is a fine approach, I find writing to the console to be more effective. There are times when the alert command makes more sense, but let’s delve into the console for a moment.
With writing to the console, you have four different message types: “log”, “info”, “warn”, and “error”. Here’s how they appear on the console:
I like to sprinkle these into my code during development. They offer sanity checks and are great when you are debugging. Most of the time, these statements aren’t pushed to production; however, if they accidentally do make it into UAT or PROD – these commands are much safer than alert messages nagging users unnecessarily.
When do alert messages make sense?
Alert messages are useful for making sure the user is told something. I try to use alert messages sparingly since when given too many users generally ignore all of the alert messages.
Profiling – Making your Code Faster
First, have you ever wanted to quantify the execution of your code within CRM? Well the profiler allows you to do this. Let’s say hypothetically you want to disable all of the fields on the form. There are several ways of doing this:
But which function would be the fastest? When comparing functions that provide the same results, it’s best to call the function more than once. So let’s call each function 100 times to quantify the speed of each call.
Additionally, let’s use this function to re-establish the form as fully enabled to make sure everything is consistent.
Here’s an example of testing the various functions 100 times each:
After executing our code, switch to the Profiler tab. Choose the speed test example and change your view to the “Call tree”. Now we can see the cumulative time of each function.
A one second difference between our fastest and slowest function at 100 times equates to an average savings of about 10 milliseconds when only ran once. Not really drastic, but hopefully this shows you how granular you can get.
Generally you won’t need to call each function 100 times. In this scenario, we were trying to save as many milliseconds as possible and comparing extremely similar functions. Typically you’d use the profiler for speeding up a slow form. By adding the profiling you can identify which functions are the culprit of any inefficiencies. Additionally, you can see if functions are inexplicably called more often than they are supposed to.