Default Control Names in Real Studio

We get asked, on a fairly regular basis, to review code in a project (that we didn’t write) and make recommendations on how to improve it.  One of the things that annoys me to no end when I review OPC (Other People’s Code) projects is when developers use the default control names that Real Studio provides in the Layout Editors.

The default naming convention used by Real Studio is the baseline minimum.  In my opinion, you have one instance where using the default name is acceptable and that’s with Labels.  And that’s ONLY if you never access the label in your code.  Really, that’s it.  Everything else should be named so that I (and I really mean you too) can read your code at a glance.

Real Studio doesn’t help us out very much on this one.  Once you’ve placed a control on the Window/Page it should, in my opinion, automatically have the control name selected so that all I’d have to do is type in the name I want and then move on.  It doesn’t despite my Feedback items from many moons ago.  At one point I was told it’s not going to be possible in the current version of the IDE.  I don’t remember by whom, or when, but I can take that at face value because the new IDE is coming soon.  Hopefully they don’t force the same bad practices upon us again.

Yeah, I know I’m being anal about this, but if I’m looking at your code and I’m trying to distinguish between TextField1, TextField2, and TextField3 and have to refer back to the layout to tell what each one is, that will be my first suggestion to you.  I’m not a mind reader and, let’s be honest, I’m as lazy a programmer as I can get away with.  Real Studio makes me use the mouse too much as it is so you’ll be better off making your own life easier too.  After all, isn’t txtFirstName, txtLastName, and txtCity much more intuitive then the original names?

We have our own coding standards document that each new developer gets when they start.  It has the list of prefixes we use for our controls (and variables but that’s a different post).  So not only does it tell me what it does (or represents) it tells me what control type it is.  So btnSave, lstNames, chkEnabled, and rbOpenAtStart is inherently clear when I see them accessed in code because I can tell control type and function at a glance without seeing the layout editor.

We have dozens of internal projects.  We have about a half dozen consulting projects at any given time.  The very last thing I want to do is look at a layout to figure it out.  My time is too valuable to muck around with the layout editor.  Your time should be that way too.  Remember, you’re coding for clarity not just for now, or five months from now, but for five years from now.  You really think you’ll remember what TextField1 is going to be by next Friday?  Do yourself a favor and name your controls something meaningful.

Heck, I don’t even care what your naming conventions are.  Just get some and use them – consistently.  You’ll be happy you did.  If you’ve watched any of my training videos you’ll realize that I take great pains to name controls.  I do this for everything.  This is one of the shames of the Real Studio example projects because many of them use the default names thus giving people new to the language the impression that this is ‘best practices’.  Thankfully this is changing a bit but it won’t be too soon for me.  I’m tired of making this particular recommendation on OPC projects.

What about you?  Do you feel this is a big deal or am I just having a really bad day?  What things so you wish Real Studio did better to help you write better code?

15 thoughts on “Default Control Names in Real Studio

  1. You’re 100% right. I hate going back and forth from the code editor to a window layout. Controls must have a consistent name so that you can’t misunderstand their use. As a matter of fact, almost any variable or element should have an explicit name.
    And I agree with you about the Label controls. Most of the times, if they are used as simple labels, I group them in an array of controls named Labels(). This way they won’t clutter the list of control in the code editor. And, If there are panels in a window’s layout, I create one array by panel and add the panel name as a suffix.
    What would be great is a simple input dialog popping when one is adding a control to a window. This way, you can’t forget to name the control, or add it to an existing array by using name autocompletion.

  2. Completely agree. It’s not just other people’s code, it’s your own code too when you revisit a project a few months down the line and try to make sense of what you have have written. The code reads much more like an English text than computer code when you use proper naming.

    Could you maybe post your list of shortcuts? It might be quite helpful to set some standard 😉

  3. You know I’m sure we’ve had this conversation before 😉

    Absolutely give all controls and variables a meaningful name. In fact, I’d argue that even labels should be named properly even if you don’t intend to access them in code: you never know if you might want to do so in the future; and it is easier matching labels with the control they are labelling if they have a proper name.

  4. By the way, to avoid clutter in the code window you could give all labels the same name “JustALabel” – the IDE will ask if you want to use them as an array where each label just has a different index. Just say Yes 😉

  5. @Markus Winter
    I’ve mentioned it before and I believe I had a BKeeney Briefs magazine column in Real Studio Developer on a similar topic.

    It came to light after a comment someone made on the beta list about the Real Studio examples having poor best practices when it came to naming controls. It then struck me like a lightning bolt that when I look at projects that’s the FIRST thing I do when evaluating whether or not to look at it in more detail. Poor control naming usually means poor variable names and poor method names.

  6. Gerard :

    Totally agree. We also insist on camelCase

    We don’t ‘insist’ on it because we’ve never had a developer NOT use it. Trust me, that would be added the minute a developer didn’t use it. 😛

  7. Read up something about this since and Hungarian notation is another name for this prefixing of variable and control names with their type in small letters. It’s also, apparently, the inspiration for Apple’s fetish for the little letter i in iPhone iPad etc.

    BTW an interesting recent blog post on the topic of coding standards:

    and subsequent discussion on hacker news :

  8. @jjb
    I read through both posts. While I agree to some extent I also disagree. A lot of the arguments in those two articles are about spacing and other formatting rules. Real Studio, thankfully, does that for us so there’s no debating if an indent is 3 spaces or 5 (one we had in our VB6 days).

    I maintain that we, as a team, have to write for clarity for projects that might show back up in our in-box 5 years from now. To be able to do that we have our standards. We are not religious about them because for every rule we all break it on a regular basis.

    The point of the standards is to encourage team development so team member A isn’t tied to a particular project and team member B can at least read the code.

    But remember, this particular rant of mine was because of reviewing other peoples code (OPC) and seeing that NONE of their controls were named. That’s pet peeve #1 and I will almost always reject a project that is guilty of that.

  9. @jjb
    I’ve been forced to use Hungarian Notation before – hated it. What we use isn’t nearly so stringent. I think most of this is because Real Studio code is datatype safe and strictly enforced. Hungarian notation was especially popular in those languages where you could do anything to any variable regardless of datatype. It was a way to help manage the danger.

    I’m not as big a stickler on the variable naming. Whether you name a variable cnt our iCnt I can figure it out. I’m okay with w and h for width and height respectively. As long as the developer is consistent in using the variables we have no complaints.

  10. Like Bob, I don’t care for Hungarian Notation either. I don’t really see the point with a strongly-typed language. If I’m not sure of the type of a variable or property, it’s pretty easy to find that out. I name things based on what they do rather than their data type.

Comments are closed.