What do you thing of this idea I'm using more and more in my code ?

What do you thing of this idea I'm using more and more in my code ?

instead of writing

if (MyObject <> nil) and (MyObject.Locked) then
Exit;

I write

if MyObject.Locked then
Exit;

with

function TMyObject.Locked: Boolean;
begin
Result := (Self <> nil) and FLocked;
end;

it can also be

function TMyList.Count: Integer;
begin
if Self = nil then
Exit(0);
...
end:

function TMyList.GetItme(Index: Integer): TMyObject;
begin
if Self = nil then
Exit(nil);
...
end;

Comments

  1. Your approach has the advantage that it can also work safely when "Complete Boolean Evaluation" is switched on in the Compiler options. For this you either have to tweak the Locked implementation to allow for this scenario or explicitly switch that off inside that said implementation.

    ReplyDelete
  2. It depends if nil is an OK condition. The alternative is to fail fast hard.

    ReplyDelete
  3. Jeroen Wiert Pluimers well I it can be an active item on a form or the item under the mouse, so something that can be nil ... and sometime I forget to test if the item exists, so puting the test inside the methods avoid a null pointer exception

    ReplyDelete
  4. "Complete Boolean Evaluation" must always be OFF. Otherwise all of our codebase fails miserably :) :) :)

    OTOH, such shorthands are nice if they don't confuse the programmer that will have to read the code after three years. (Which may as well be the guy/gal who wrote the code.)

    ReplyDelete
  5. Are sure the next programmer (or yourself in 3 years) will know that calling these methods is safe?

    ReplyDelete
  6. Thomas Mueller probably not, but then nil will be tested twice without adding a bug :)

    ReplyDelete
  7. This is the same technique used by the Free method.

    ReplyDelete
  8. Any chance of undefined behavior? Is it documented somewhere, that calling method of nil pointer is allowed?

    ReplyDelete
  9. Virgo Pärna like Christen sayed, Free is such a method :)

    ReplyDelete
  10. Paul TOTH I know:)
    But maybe it is just special case. It just reminds me those optimizations removing undefined code type of problems in C or C++. Current Delphi compilers are allowing it anyway.

    ReplyDelete
  11. Virgo Pärna, just take care of not using it with virtual or dynamic methods.

    ReplyDelete
  12. if MyObject?.IsLocked = True then

    ... oh wait, we don't have that (yet) ;)

    ReplyDelete
  13. Stefan Glienke oh yes, we could also have

    lock = (MyObject?IsLocked ? LOCKED : UNLOCKED)

    or still use some Pascal afterall

    ReplyDelete
  14. I think it is a very bad idea and I truly hope that other Delphi devs don't start using this in their own code. TObject.Free() is a special case it is valuable and - believe me - lots of devs don't really know how it works internally. Now imagine a huge code base where you have to check each individual method to find out if "this works like Free or works the other way around"? A nightmare.

    ReplyDelete
  15. Method name should be AssignedAndLocked to avoid confusion.

    ReplyDelete

Post a Comment