Hi Andrew,
> Still plodding along with the idea of an example database
Glad to see this topic doesn't let you rest ... ;)
> I am not sure if there is any documentation to be found on this subject:
> What is considered good practices and what is to be avoided.
I'm not sure, either, but I suppose there isn't ...
I can put up my own thoughts on some general questions of how code
should look like, no regard of the language it is written in. Be aware,
however, that it's exactly this: My personal preferences. Though, if
asked, I'd claim that some of those preferences have proven to be useful
over the years, it's still a personal habit only ...
> A couple of things: the file includes the database and a uno.pkg file
> made with the new 2.0.3 library export feature. What do people think of
> this as the way to distribute any required basic macro libraries?
The best way would be if the Base documents themself would allow for
Basic code ... 'til this is given, and in cases where different
documents share the same code, I think the UNO packages approach is great.
> Another thing is that I did not include any comments in the code. My
> attempt was to make it self documenting...*chuckling*...it is Basic
> after all.
I'm a big believer in comments :), but more for the used concepts than
for the actual things happening.
a = 3 ' assign 3 to a
foo( a ) ' call foo with a (which is 3)
is the usual kind of example how *not* to comment.
However, explaining *why* certain things happen in the code (and not
*that* they happen - this is what the reader can already see) is always
a good idea IMO.
Of course, the necessity for comments decreases with various other
things, for instance with well-named functions.
foo( abc )
is more likely to require a comment than
insertAndAnalyze( oList, oNewElement )
The drawback of "too much" comments on the other hand is that over time,
they tend to get out-of-sync with the code they were supposed to comment ...
> sub onChangeRecord( oEv as variant )
> dim oListBox
> oListBox = ThisComponent.CurrentController.getControl(
> oEv.Source.getByName( "lbxInterests" ) )
> FieldToSelectedItems( oListBox, Separator, oEv.Source,
> "ClientInterestes" )
> end sub
>
> The line oListBox=.... is a place where someone may wonder why in the
> world be so convoluted - well I know that I am going to want to use a
> method on the CONTROL that is not available via the controls MODEL. In a
> case such as this should I have made a point of bring this up in a comment?
Here, I'd tend to break up that line
Dim oListBoxModel as Object
oListBoxModel = oEv.Source.getByName( "lbxInterests" )
Dim oListBoxControl as Object
oListBoxControl = ThisComponent.CurrentController.getControl( _
oListBoxModel )
(we could even separate oEv.Source into a dedicated oRowSet or oForm,
making even clearer that this event is expected to be triggered by a form.)
This is more to type, but usually more effort when writing pays off when
reading. ("Beware to write 'write-only' code" is one of my favourite
rules in a famous book on using STL in C++ - this is somehow related to
the topic here.). Remember that code usually is more often read than
written, since you sometimes need to maintain it over years ...
> Acually here is another thing about that sub procedure - it's name.
> onChangeRecord, I am calling it from the event 'After Record Change'. In
> looking at it now I think perhaps it would be a good idea to try and
> keep the names in synch. So perhaps it would have been better to name it
> onAfterRecordChange...again what do other people think on this?
Yes, perhaps. I'm not that strict here, since I think that the UI names
for the events are not always good chosen, so I dare to generally use
them as template for method names ...
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
