So…let’s say you’ve developed a really cool, really complicated DataBlock. It has 5 forms, 15 multi-column list boxes, 20+ parameters and a dozen SQL variables. A month after it goes live, a director comes up to you and says, “This would be even more useful if the report had some changes.” In the time since you deployed your masterpiece, you’ve worked on several other DataBlocks, but now you need to revisit your pride and joy and make the requested changes. Unfortunately, you didn’t give any of the DataBlock elements a meaningful name. Now you’re stuck, poking through a huge list of variables trying to remember exactly what’s going on and which parameters need to be changed. Sound familiar?

If you’ve ever found yourself in this situation—either because you stick with default names or leave renaming until the end of your development process where it sometimes falls off the to-do list—then I’ve got an easy solution for you: naming conventions. For those of us frequently on a deadline, the temptation to leave the default names and keep moving is often strong. But even if it takes an extra moment, I highly recommend giving every DataBlock element a meaningful name, and do it as you go. Why? There are a number of reasons:

Reason 1: You win the lottery.
All right, so you’ve just won the big jackpot. You walk into work Monday morning and quit. Now, one of your colleagues has the thankless task of trying to pick up where you left off. If you have left the variables and parameters as the default, that person is stuck trying to determine which parameter goes on each form and what they each do.

Reason 2: You have more than one DataBlock in progress at a time.
Probably a more plausible scenario than the last, let’s say that, in any given week, your development time is spread across several projects at once. Constantly changing priorities, the weekly barrage of meetings and other disruptions can cause your work-in-progress list to shift daily, sometimes hourly. Putting a DataBlock down and picking it back up hours, days or even weeks later is more common than completing one in a single session. If you haven’t named anything, it will take some time—every time—to pick up where you left off.

Reason 3: You work on DataBlocks with multiple developers.
If you happen to work in an environment where developers hand projects off to other developers or share development time on a project, standard development procedures are a must-have. (This, by the way, should include not only naming conventions, but also documentation, comments and standardized user interfaces.) Having clear, intuitive names for everything speeds up the hand-off process considerably. The developer taking over knows exactly what to expect and can quickly come up to speed on the type, purpose and location of every element.

Reason 4: You don’t like repeating your work.
Although many developers leave naming until the end of their development process, as part of their documentation, doing this in Argos would be a very bad idea. Changing the name of a parameter AFTER you have built the DataBlock will not change every occurrence of that parameter within the DataBlock. This will cause syntax errors and ultimately, a lot of extra work on your end to find every occurrence and change the name manually. Better to add a meaningful name as soon as you create the variable or parameter, so that as you continue building, your design will reflect the correct variable names.

Worrying about such a small detail may still seem like a waste of precious time, but which of these lists would you rather work with:

The list above is fairly small, so it may not seem like much. However, as you begin to get into more complex DataBlocks, multi-form dashboards or detailed banded reports, naming conventions take on a whole new appeal. Take this for an example: I recently completed a banded report that has over 100 expressions, labels, variables, bands and other objects. If I have an element called ‘Expression27’ what does that tell me? Not much. Now, if I’d named it ‘HB3_EXP_ResetBudgetSubtotal’ instead, that’s a different story. ‘HB3’ tells me that it’s on the third Hidden Band of my report, ‘EXP’ tells me it’s an expression, and ‘ResetBudgetSubtotal’ describes its function. The [location]_[type]_[purpose] formula is fairly easy to follow, and you can always tailor it to your needs. (Check out these lists of useful abbreviations – one for DataBlock Designers and one for Report Writers.)

Although this little step may slow you down a bit in the beginning of the development process, in the long run, you will be glad you took the time to use a good naming convention. In future blog posts, I will give you some tricks on how to speed things up, to make up for any lost time spent on naming!