Clean Code: Writing Code for Humans

I am a proud monthly subscriber of the online training website Pluralsight. I cannot imagine staying up to date in this field without that subscription. Since my blog focuses on Salesforce concepts, I will tell you that Pluralsight offers several brilliant courses that cover Salesforce.

CleanCodeBut, this post is titled “Clean Code: Writing Code for Humans” by Cory House, a brand new course just offered on Pluralsight. The course is described as the following:

“Anyone can write code a computer can understand, but professional developers write code *humans* can understand. Clean code is a reader-focused development style that produces software that’s easy to write, read and maintain.”

If you are new to programming (of ANY language), then this course if for YOU!

Even if you are an experienced programmer (of ANY language), then this course is for YOU TOO!  I have been doing software programming for over 20 years and have regularly espoused many of the concepts covered in this class, and I learned plenty by watching it. We are ALL prone to writing dirty code and this course has great practical advice for how to avoid this.

If your goal is to remain a programmer (more specifically, a productive and respected programmer), then this course is definitely for YOU!!!!!

Even if you do not already have a subscription to Pluralsight, never fear, they offer a free 10-day trial subscription. So, you really have no excuse. Go and see it I tell you.

Proper Use of ActionStatus component

In preparation for the Advanced Developer exam, I have been painstakingly going page by page through the Visualforce Developers Guide (which can be found online here). Almost every single person that has passed the exam has suggested that you become intimate with this document, but I wonder how many people truly are. I keep finding that the code listed in the tutorials does not work as it should. My last post was about one such error and now I have another big one.

On page 44 of the guide, they provide an example of using the ActionStatus component to provide a status for Ajax operations. Great! It is an awesome tool, but unfortunately, the code example they provide on that page does not work. If you copy the code from this tutorial and use it in a page and then try to see the text, you will not see it.

You can however, make two simple code changes to the code they provide and it will work as promised. But, only if you do this, will it work. So, the code that does work is seen below. What the tutorial authors missed was that an id attribute is needed for the ActionStatus component and that id value must be referenced in the status attribute of another component on the page.

ActionStatusProblemCode

Hope this helps someone else from not being confused about how ActionStatus is supposed to work. At first, I thought I was just not seeing it quickly enough (silly me…)

Setting Tab Order – Use TabOrderHint instead of TabIndex

In the last few days, I have been preparing for the Advanced Developer Certification by going page by page through the recommended Salesforce Developers Guide. I was shocked when I received an error trying to save a sample page using the code supplied in the online guide (page 39). The sample page involved setting the tab order for fields in a form and the code referenced an attribute named TabIndex. When I attempted to save the sample page, I got the following error:

Unsupported attribute tabIndex in <apex:inputField> in myPage at line 5 column 56

In my experience so far, Salesforce has been excellent about keeping their docs up to date, but I am afraid this one may have slipped through the cracks. After doing a search through some forums, I discovered that the tabIndex attribute was replaced with a new attribute named tabOrderHInt in Winter 12. So, any code created since then (which is about a year at this point), will not work using the code example supplied in their online Developers Guide.

Updated Podcasts of Apex Training

UPDATE: According to Chris Barry , the instructor in these pod casts, Salesforce has removed them because they are now focusing on new/better low cost training. As soon as I learn more about what that is, I will post about it here.

For anyone studying for the Salesforce Advanced Developer Certification, I strongly suggest you check out the following recently refreshed series of Podcasts posted on ITunes. They are recorded sessions of a fairly recent (from the Spring 2013 time frame) class given by Chris Barry at Salesforce.

There are some differences between the online premier training and the in-class training, but for the most part, you could follow the notes posted on this blog as you watch the Podcasts. Just keep mind that the episode about the Developer Console is very out of date, since the Developer Console has changed dramatically in the Summer release.

Lessons Learned While Writing Apex Code

I have been writing object-oriented code for several years and specifically writing Apex code for over a year now, yet every time I go to create a new class or a trigger, I feel like I learn something brand new. This post is a summary of some of the most important lessons I have learned. I hope it helps you to avoid some of the same speed bumps that I have encountered.

Tip #1 – Make sure you “Bulkify” every Trigger

This is “THE BIGGEST TIP”. It is probably the one you will see the most written about, but it is so critical to writing good code, that I think it is ok to re-stress the point. In case you do not know, bulkifying a trigger means that the trigger can effectively handle being executed numerous times (200 times typically). trigger

Why 200?

Well that is usually the maximum number of times it can be executed (depending on the context). You see, your trigger can be executed multiple ways. It can be executed by users performing actions in Salesforce, or it can be executed by someone bulk loading data through the Apex Data Loader or the API. If your code is not written efficiently, it could very well throw the dreaded “Too Many SOQL Queries”. Trust me, you do not want to see this message.

So how do you avoid it?

Glad you asked. I am not going to bore you with a long detailed explanation of what you can do to bulkify your triggers, because honestly that has been done to death. I will however, tell you the golden rule to remember when writing triggers:

“If any of the following statements (SELECT,UPDATE, INSERT,DELETE) appear within a for loop, your code needs work.”

Basically, if any of those statements (which represent either a SOQL Query or a DML statement) appears in a for loop, this means you are executing a very expensive operation numerous times (or at least as many times as the loop iterates, perhaps even more). Avoiding expensive database calls is a common thing to avoid in any programming language, but is especially important for Apex development because of Salesforce’s Governor Limits (which imho are GREAT for ensuring that we all create the best code possible).

If you want to learn more about all the things you can do to bulkify your triggers, check out this very informative post by Salesforce Guru, Jeff Douglas. Everyone should also checkout the post on the DeveloperForce Wiki titled, “Apex Code Best Practices“.

Tip #2 – Create at least two testMethods in your Unit Test Code

Most posts or instructions I read did not really stress the importance of creating both a single instance and bulk instance testMethod in your test class.

Why two methods and not just one?

The first method should be for testing what happens when a single record is handled. It is here that you should include System.AssertEquals to test whether a condition is true. This will tell you whether the trigger actually did what it was supposed to do.

It is possible to write Unit Test code that does not do this kind of check and still get 100% coverage. However, I would not consider the test to be a good one and neither should you.

The second test method should cover what happens when the trigger must handle multiple records. The following code is an example of using two such methods to test the validity of a trigger.

TestBulkCode

Tip #3 – Bulkifying your code is not just important for triggers

So what else is it important for?

How about Unit test code contained in class files – especially the ones that were built while keeping tip #2 in mind. That’s right, even your unit test code needs to be written efficiently – especially when it is set to execute a bulk testMethod.

If your Unit Test code uses a For loop to create a set of records and performs a SOQL query or a DML statement within that loop, guess what? Not only might you get an error, but your code is going to take way longer than it should to run tests and ultimately deploy.

This tip also applies to methods contained within a Helper class. The more efficient your code, the better, so always assume the worst and expect all of your code to be called multiple times.

Tip #4 – Use Both the Developer Console AND the Force.com IDE

I have been very impressed with the newly available Developers Console. For a long time, the Force.com IDE was hands down the best tool for developing Apex code, but I feel like that is starting to shift – a bit, at least.

For some tasks, I prefer using the Force.com IDE – like for just browsing and editing code. I also love the schema editor for examining metadata. However, I am discovering that there are certain tasks that I prefer the Developer Console for.

The biggest thing is for running Unit Tests. In my experience, the Developer Console is many times faster at executing unit tests – especially the ones that test bulk methods.

I also like the way the execute anonymous code area is right at the top of the Console. It just makes more sense to me in this spot. I also like the layout of the Query Editor tab and especially that it returns the value of an AggregateResult (see image below). This is something you cannot do with a query in the Schema Editor of the Force.com IDE

DeveloperConsole

If you have not checked out the Developer Console or only glanced at it, I encourage you to give it a look. Try doing some tasks in one tool and then switch to doing the same task in the other tool. You may be surprised by which you prefer.

Tip #5 – Periodically go back and evaluate old code

Just like no two people will likely write the same identical answer to an essay test, no two developers will write the same development code (unless of course, you copy someone else’s code). There are dozens, maybe hundreds of ways to code some things and most ways involve inefficient code. Chances are high that you have written at least one piece of code that can be improved.

Learning how to be an efficient developer is a process. You do not learn it by reading one article, one book, or one post. It takes time to develop the skills to write efficient code in every situation – especially when you are new to a platform or language. Set aside time (say once a year) to periodically go back and evaluate old code you have written. You will probably be surprised at how much you can learn in a year.

On Being a Certified Salesforce Developer

sf_cert_dev_rgbAfter six very intense weeks of study, I finally cemented my status as a Certified Salesforce Developer on March 9, 2013. As a former Microsoft MCSD, MCDBA and MVP, let me just say that Salesforce sure ain’t giving these things away. The test was VERY tricky and reminded me of the certification tests for Microsoft SQL Server (those were not easy either).

The funny part is that if you look at the official logo on the left, one might be led to think that the large slash through Software would indicate this stuff is a piece of cake. That is not exactly the case.

While I will admit that Salesforce has removed many of the complexities associated with software development, such as setting up and maintaining development and database servers, it has not totally done away with software (as their logo might suggest). What they have done is expose to small and mid-level businesses the potential of using some very highly functioning and scalable business applications through their affordable and subscription-based cloud-based platform.

As a software developer with twenty-years of experience building enterprise-level business applications for a variety of industries, adding the expertise of cloud-based development using the Force.com platform was a no-brainer. I simply cannot lose with this certification. The demand for highly-trained cloud-based developers is sky rocketing and I intend to strap myself to the top of that rocket.

In the next few weeks, I will continue my education as I prepare for the Salesforce Advanced Developer Certification. This distinction will be even harder to get, as I need to not only pass a grueling test, but I also need to complete a programming assignment and then defend my programming choices in a proctored essay exam. I feel like at the end of this I will have earned a Salesforce PhD.

I am using the excellent Premier Training available from Salesforce to do most of my training. In the coming weeks, I will be posting notes from the online training in hopes that it benefits anyone else out there trying for this certification. There cannot possibly be too many of us. The better trained other developers are in this field, the easier it is for me to work with them. It is also better for me, because they will be producing good solutions that highlight the platforms enormous potential and create opportunities for EVERYONE!

Please share with me your thoughts about cloud-based development and specifically the Force.com platform. I would love to hear from you.