More good habits

On the forum there was a suggestion that a person should use a container control that had a few controls embedded in it at design time. And then when using that container control that they should skip providing an API that the container presented and just reach inside the container and manipulate the controls it contain directly.

Personally I would recommend against this.

I’d start by saying when you create a container control ALL the controls in it should be private by default to prevent this. And that if you want to expose functionality of the controls on the container you do so by defining methods and events on the container that any code OUTSIDE the container can call or react to just as if the container control was any other single control and not a composite one like it is.

Why would I make such a recommendation ?

  1. good habits
  2. encapsulation
  3. reusability
  4. long term flexibility and maintainability

The first point is just that this is a good habit to get into. And the reason its a good habit is because of points 2, 3 and 4. Properly encapsulating and hiding the details from other bits of your code is a good thing. Code outside the container doesnt need to know HOW the container does what it does. Just that it does what is expected when you call its methods, change its properties and react to the events it exposes. Thats it. It should be a black box like the built in Xojo listbox, pushbutton, or any other built in control is. You dont need to know how those do what they do, just that they do what you expect when you call the methods, set the properties and react to their events.

And the bonus to doing this is that it makes the likelihood you, or others, can reuse your control in more places in your project or in other projects much higher because the control is self contained.

Long term it also lets you do things like completely swap out the implementation of the container for some other means and as long as you dont need to change the API nothing outside the container control even needs to be aware this has happened. This makes your own code easier to maintain since you no longer have to look through all the code outside of the container to know if you also need to alter it because something in the container changed.

These are all good things regardless of whether this code is for your own use, more general distribution or possibly for sale or to give away.

I’d encourage everyone to keep these things in mind when ever they write their own custom controls.

Coding style

Thomas Templemann wrote a nice blog post about his preferred coding style guidelines.

And most I absolutely agree with.

Except one.

His suggested style is to test booleans simply for the value they hold and not to test for TRUE or FALSE explicitly. He considers testing for TRUE or FALSE bad style. Examples of bad style are :

if hidden = true then ... // bad style
end if
if hidden = false then ... // bad style
end if

Instead he suggests using good names and the following style

if isHidden then ... // good style
end if
if not isHidden then ... // good style
end if

Personally I find that sometimes picking a “good name” so things read like an English sentence can be challenging and that any code you get from someone else may not adhere to the “good name” principle.

As of late I’ve been working in a lot of code written in German. All the variable names, controls, etc are German. And so nothing reads well to me since I don’t read German.

So I prefer a style like

if einigeWirklichSchrecklicheVariablennamen = true then ... 
end if
if a这儿没有发布参数和返回值 = false then ... 
end if

All this said whatever style you use stick to it and use it consistently throughout your code. Use Thomas’s if you like them and they work for use. Or those from BKeeney. Or write your own set, try them out and work with them and tweak them until they make code easier to write AND easier to read and comprehend when you’ve been away from it for months at a time.