One of the tricky parts of learning to code is knowing where to put all the fabulous stuff you’re writing!

Your classes go one place, your triggers go another, and what about testing your SOQL or running your Unit Tests? It can be very confusing for sure if you’re new to this code stuff.

With this post I hope to clear up some of that confusion and get your started on your “Road to Code.”

Together we’ll check out the three main tools used to create code within the Salesforce Environment, and talk in depth about one of them: the Developer Console.

But don’t worry (and I know you are … go on admit it!), I’ll do a deeper dive on others in future posts.

Tools to Write Code

There are three basic tools that allow you to write code. Two of them live within Salesforce and the last is more of a category of tools.

Let’s start with the tool most familiar to Salesforce admins … Salesforce Admin Settings!

Tool #1 – Salesforce Admin Settings

Almost everything that you need to do with coding is available right from your trusty Salesforce Settings right under the Develop menu.

So while good ol’ familiar Settings might seem the best place for an admin to start coding, you’ll likely quickly become frustrated. The options within Settings do give you access to all your code, but they don’t give you much functionality beyond that.

For example, there are no debug tools, no code completion, and not much that makes it easy to program.

So while Settings is a good place to quickly view what you have running in your org, it doesn’t have enough tools to make it easy to write code.

Let’s move on to a much better tool, the Developer Console.

Tool #2 – Salesforce Developer Console

The Developer Console is collection of tools that you use through your web browser. How convenient … I have one of those! (For the record, I use Google Chrome.)

Through your browser and the Developer Console you can create, debug, and test your Force.com code. It’s accessed through your Salesforce Org, by clicking your name > Developer Console.

The great thing about the Developer Console is that it’s immediately available … no downloading and installing of any programs, no figuring out what your API key is. It’s all about the immediate gratification; kind of like eating a perfectly created Pain Au Chocolat … one made by your local patisserie … not one that you slaved over making for hours. We’ll get to that later.

For beginning coders, I highly recommend the Developer Console for a great balance between ease of use and additional functionality. Plus it has the added bonus of being used in pretty much all Salesforce Developer education materials (e.g., Workbooks, Trailhead, etc.).

But before we roll up our sleeves and get a closer look at the Dev Console (as it’s known by it’s friends), let’s look at our last category of tools. Those that live outside the Salesforce environment.

[Type of ] Tool #3 – External Developer Tools

There are several tools that are external to Salesforce, but allow you to interact with your Developer and Sandbox environments. We’ve talked about one before, Workbench, but let’s look at a couple coding environments.

The two biggest examples are the Force.com IDE* (based on the Eclipse platform) and the Sublime Text Editor with MavensMate add in.

*IDE stands for Integrated Development Environment. Basically it means software that helps you develop and connects directly with the place your code will actually live.

These are both amazing tools that give you a whole series of functionality to make creating and managing code easier.

So if they are so awesome, why not start there?

I think, as a beginner, it is better not to have any more barriers in-between you and getting that #$?%#@?!! code to work than is absolutely, positively, necessary. And, well, for me that means that the Dev Console has the right balance between ease of use and rocking “get-‘er-done” functionality.

There is quite a bit of debate in the Salesforce Dev community between the benefits of both the external dev tool front runners, so I’ll definitely cover how to set them up and the pros/cons between them in later posts.

But for now, let’s check out my newbie-dev-tool-of-choice, the Developer Console. (Yay!)

First things first…

Probably the first thing you’ll want to know is how to access the Dev Console:

1. Log into your dev org or sandbox.
2. Click on your name and choose the Developer Console.

Easy as pie! (See what I did there? Unfortunately turns out it’s hard to work cooking references into a post on the Dev Console).

Once you get in there, you’re probably super excited (I know I was … “oooh code lives here!”). So take a slow, deep breath and let’s take a look at all the bits and bobs.

The easiest way to orient you is to show you what some code looks like within the Dev Console. Below we have a class (OpportunityUtil) within the console.

It’s really not much to look at in terms of code, but it’s good to help orient you.

You’ll see at the top (in yellow) that all your open files will show in tabs. Anything with an asterisk needs to be saved and compiled.

The great news is that, unlike with Java, you don’t actually need to do anything to compile your code. You save the file, and voila! If there are no problems with your syntax, then your code is compiled (so satisfying!).

Once you have a file open, all that delicious code goes into the body of your open file – see the area in blue.

Don’t look now…errors ahead!

If you try to save the file, or even before that as the Dev Console periodically tests for syntax errors, you may see that lovely little red “!” in the sidebar with the line numbers. (See above in line 6).

Don’t panic! This is 100% normal and expected. There is no developer (or well…none I know) who doesn’t get this pretty much any time they write code.

It just means that something isn’t quite right.

Luckily 80% or so of the time the “!” shows next to the line which is causing the problem. Yay!

The other 20% or so it’s likely above where the error marker is showing. It’s sometimes hard for the console to know exactly what is causing the error.

But here’s a tip … look for semi-colons in the wrong place, ask my fabulous #DF15 Force.com Coding Tour session audience, <sniff> love you guys!  Yep, on stage, in front of hundreds of people I lost a semi-colon. It happens. Luckily for me I had help from come trusty code reviewers in the audience (#headSlap) and we pretty quickly got back into the swing of things.

Really it was a planned demonstration for all that errors happen! (Yeah right!)

So beyond where the error is, you can also see some hints on what the problem is, within the aptly named “Problems” tab below your code window.

This is where you get some (mostly helpful) guidance to what is wrong with your code.

For example, above we can see we have a problem on line 6. The problem tab shows the compiler expected a semi-colon, but instead found “opps.NextStep.”

This is one of the times when the error is actually on the previous line, and yes, it’s that pesky little “;” that I missed on the line above.

You soon get used to reading these kinds of errors and fixing the problems as they come.

Believe me … you’ll get LOTS of practice.

What other cool things can we do?

There are all sorts of other goodies under the other tabs below the coding window. We’ll cover some of them later, but think SOQL query editor, running and viewing the results of unit tests, and viewing your debug logs.

Whaaat! I know…like sooo cool!!

Next Steps with the Developer Console

So now that we’ve taken a peek around, let’s get on to the really good stuff…how to create new and open existing class and trigger files.

It’s actually pretty straightforward to do this.

To create a new class

1. In the menu, click File > New > Apex Class.
2. You’ll be asked to name the class.
3. Then you write your code and save it.

To create a new trigger

1. In the menu, click File > New > Apex Trigger.
2. You’ll be asked to name the trigger and say what object you are working with.
3. Then you write your code and save it.

Easy right? But what about opening files that already exist (seems important). Still easy!

Opening existing files

1. In the menu, click File > Open.
2. In the left side of the window, select the type of file you want to open (e.g., class, trigger, Visualforce page, etc.).
3. Then you can double click in the middle panel the file you want to open.

If you single click on a file, then you can see all the related resources (which is helpful to orient yourself to what that piece of code does).

In the Related window, if the item has an arrow before it, then you can click on that and it will load the resource in the middle window.

The Code with No Name (aka Execute Anonymous)

Sometimes you want to just run a piece of code (in Dev/Sandbox first please!) and see what it does.

That’s when Execute Anonymous comes into play.

Note that you can’t save code in Execute Anonymous. It will generally show you the last code you worked on. But it is a great way to test out sections of your code and to learn to code because you don’t have to set up a bunch of structure to test out a concept (e.g., loops, DMP, collections, etc.)

To create and run code in Execute Anonymous window

1. Click Debug > Open Execute Anonymous Window.
2. Type your code in the window.
3. Check the “Open Log” box.
4. Click Execute.

If there are no errors, then your code will run and then you’ll see your debug log.

If there are errors, then they will appear in a dialog box.

No Flies on This Code! (aka the Debug Log)

The Debug log shows everything that happens programmatically in your org. If you just ran a piece of Execute Anonymous code, then it should pop up after the code is finished executing (if you checked the “Open Log” box).

It will look something like the screenshot below. If you just want to see all the lines that you wrote using System.Debug(); statements, then check the box that says “Debug Only”.

Another way to filter your Log

You can also use the filter checkbox and the field next to it to type in code and look for specific things in your debug log. Note, that this is CASE SENSITIVE.

But My Debug Log doesn’t look like that!

If your debug log looks more like the screenshot below, then you will want to set it to something less cluttered.

To do that:

1. In the menu, click Debug > Perspective Manager > Log Only

What other Cool Stuff can I do with the Developer Console?

I mentioned earlier that there were some other cool features hiding under the tabs below the code window.

Let’s check those out.

Run SOQL

Click on the Query Editor tab, and you’ll find all sorts of tools to work with SOQL Queries. Including create new ones and accessing and re-running previous ones (yeah…that was another #headSlap moment in a #DF15 session – I swear that I’m a professional! #doh).

You can also interact with the data either in the query result, or through salesforce forms.

Be super careful when you create or edit records via the SOQL Query results, because you are not going to be running any validation, and it’s VERY easy to delete records.

Execution Logs

Click on the Logs tab and you can see all the execution logs for Triggers, Classes, and Execute Anonymous that you have run during your current session

Apex Test Coverage

You can run tests and also look at your percentage of code coverage (including which lines of Apex are not covered) and see any errors in your test coverage.

We haven’t yet talked about Unit Tests on WomenCodeHeroes, but when you get ready to run them, check out the information below.

To run all unit tests

1. In the menu, click Tests > Run All Tests

To run selected unit tests

1. In the menu, click Tests > New Run
2. Select the tests you want to run and send them to the “Selected Test Classes” box
3. Click Run button

What am I seeing?

• All the times you’ve run the tests are in the bottom left:
  • You can see what parts of the test code is finding what it expects.
  • Green check is a passed test
  • Red cross is a failed test
• The Apex classes/triggers that is referenced in the tests are to the bottom right:
  • Doubleclick on one to open it above and show which pieces of the code are covered
  • Code in red is not covered
  • Code in blue is covered

Wrapping Up

If you mention developer environments to any group of developers, they will most likely have a spirited discussion of one IDE over another.

I completely agree that there is huge benefit for setting up these types of systems. AND, when you’re new, I believe you shouldn’t let anything get in your way, and setting a system to code in is, in my mind, an unnecessary barrier for a new coder.

Hopefully I’ve shown you that you don’t have to wait to get your code on. Let me know if you have questions through the comments and I’ll add to this post!

And up next time, we will tackle the all-important topic of Unit Tests!  Woot Woot!