[Developers] Choosing meaningful names for user interface objects

Jaap Glas Jaap.Glas at dgb-group.com
Fri Jan 18 10:46:11 CET 2008


Dear fellow developers,

Choosing meaningful names for user interface objects
====================================================

A posting by Nanne Hemstra (dGB India) on October 29, 2007 suggested me
an idea to write you about the importance of choosing meaningful object
names when initializing user interface objects. I copied the following
code lines from that posting:

> uiGroup* leftgrp = new uiGroup( this, "Left group" );
> // add fields to leftgrp
>
> uiGroup* rightgrp = new uiGroup( this, "Right group" );
> // add fields to rightgrp
>
> uiSplitter* splitter = new uiSplitter( this, "My Splitter", true );
> splitter->addGroup( leftgrp );
> splitter->addGroup( rightgrp );

The names "Left group", "Right group", and "My Splitter" are of course
just dummy names chosen for this example only, but the truth is that
the current OpendTect code contains really a lot of names like this,
and worse. Empty names are given, or the default name is passed by
giving no name at all. This may not be such a big deal for passive
objects like groups and splitters, but it certainly is going to be
for interactive objects like buttons, input fields, lists, etc.
Why is it so important to choose meaningful and (locally) unique
ui-object names?

We are currently developing a command driver which will offer
automated control over OpendTect from a command file. The command
driver is going to be used for scripting, automated demonstration,
and automated testing. The user writing a command file has to tell
OpendTect literally which buttons to push, sliders to pull, wheels
to turn, etc. By far the easiest way for the user to address these
ui-objects will be by means of their object names. And for iconized
buttons for example, it is about the only feasible way to do so.

So when witing new user interface code, or editing old code,
start using meaningful and (locally) unique ui-object names.
It will really facilitate OpendTect users in the near future
to use your applications in an automated context. Our plan is to
supply OpendTect 3.2 with a first version of the command driver.
And finally, be reserved in using funny or dirty ui-object names,
since these are no longer going to be visible to us developers
only ;-)


Best regards,

Jaap Glas.

-- 
-- dr. Jaap C. Glas
-- Software Engineer
-- dGB Earth Sciences
-- Nijverheidstraat 11-2
-- 7511 JM Enschede, The Netherlands
-- jaap.glas at dgb-group.com
-- http://www.dgb-group.com
-- Tel: +31 534315155, Fax: +31 534315104




More information about the Developers mailing list