Do Until with Loop Until

General
1

I’m using Xojo for more than eight years und I’ve just discovered that both together are possible: see sample below. That’s makes While…Wend superfluous and is more elegant than checking two variables via AND/OR. Does anyone else?

[code] dim data() as string = array( “foo”, “”, “bar” )
dim index as integer = 0
dim error as boolean = true

do until index > data.Ubound
//
// processing data
//
error = ( data( index ) = “” )
if not error then

  //do something with valid data( index )
  
  index = index + 1
  
end if

loop until error

//will end with error because data( 1 ) is empty
//will also end with error if there is no data (array data() has no items)
[/code]

2

You’ve got the validation for whether the loop should continue in two different locations.
I personally don’t like that, and think it would be harder to read and find quickly.

I’ve been learning from Bob that making your code as explicitly obvious as possible is the best way to go. For example, recently I’ve stopped using if boolean then, and explicitly make it if boolean = true then just so we can skim through code faster. In the last several months my code has become so much easier to read, and I really appreciate him for it.

3

just because you can doesn’t mean you should :slight_smile:

dim error as boolean = true
  
while index <= data.Ubound
    //
    // processing data
    //
    error = ( data( index ) = "" )
    if error then exit while
      
      //do something with valid data( index )
      
      index = index + 1
  wend

this is why While/Wend exists

4

Yes, at two different locations; at the start and the end of the loop :wink:

Tim, I think you never code if boolean.... If the boolean has a meaningful name like “error_occured” or “array_is_empty” then if array_is_empty then or if not is_array_empty then is very easy and clear to read for me. Does someone code if ( 1 = 2 ) = true then?

5

@Dave: With While/Wend you need an Exit While “somewhere” in the loop. Makes this your code easier to read?

6

I am a huge advocate of meaningful variable names. We even use type-prefixes on our variables, so a real life example would look like this:

if bErrorOccurred = true then // Do stuff end

Even with the meaningful variable name, AND the variable prefix telling us it’s a boolean, I still find it easier and faster to read by explicitly stating we’re looking for true in the code. Even though it’s implied in the if boolean then

Everyone has their own style, there is no wrong way (except to put spaces after parentheses) so it’s all just commentary :slight_smile:

7

Some forms of this are called “Hungarian” Hungarian notation - Wikipedia

A problem can be if the name is wrong or leads one to believe the wrong thing.

For example:

dim bErrorHappened as boolean = FunctionThatReturnsTrueOnSuccess(foobar)
...
if bErrorHappened then
   // take steps to handle the error
end if

In this example, the “bErrorHappened” variable is inverted from what’s expected.

8

In your example the value is being assigned poorly, and whatever issues that may occur are the direct result of the person who wrote the code.

For your example, I can think of at least these two options:

  1. Use a better variable name, like bFunctionWasSuccessful
    or
  2. Invert the result from the function that returns true on success:
dim bErrorOccurred as Boolean = not FunctionThatReturnsTrueOnSuccess(foobar)
9

Yes of course, but that’s not the point really. The point is that having a descriptive variable name (or descriptive comment) in code - when the description or comment is wrong, can make things really hard to debug.

I’ve seen recommendations that really good code should be self documenting and not require either ; I’m afraid I’m not that good of a programmer :slight_smile: