My favorite example of novice programming:

My favorite example of novice programming:

if SomeCondition then
  SomeVar := True
else
  SomeVar := False;

because

SomeVar := SomeCondition;

is too easy.

Comments

  1. my favorite boolean evaluation is:

    if somevar=true then
       ...
    else
       ...

    never understand why they need to compare with true or false. found this gem in several languages, pascal included.

    ReplyDelete
  2. I use the compare to false often in order to obtain a true result :)

    I find "If SomeVar = False" is in many ways clearer than "If Not SomeVar" because to do the "Not" bit you need to use indirection instead of a simple comparison to true of a false value :)

    Regards,

    A

    ReplyDelete
  3. Of course if the variable has a negative in its name it doesn't matter how you compare it. It's still confusing.

    if not NotOpen then

    if NotOpen = False then

    if not NotOpen = True then // ok now we're getting silly

    ReplyDelete
  4. obviously I don't do that :-) The usual one for me is something like If HasThisOrThat = False then...

    ReplyDelete
  5. Kenneth Cochran It's interesting how often this comes up. In my earlier life as a hardware designer, I learned that most of us do not think well in negative logic. Of course, hardware guys are rarely too ashamed to do a little Boolean algebra to sort things out; few of the software guys in my years of experience ever do that. But I digress....

    In general, designing terms to be positive results will make it easier to be certain of correct logic. Depending on the complexity of the complete expression, it may also be beneficial to proceed in stages. 

    That said, I dislike intensely seeing an explicit test against either false or true.

    ReplyDelete
  6. Sorry, ugly function for lazy guys, alternative IIF with silly Variant:
    function IIF(Statement: Boolean; TrueValue, FalseValue: Variant): Variant;
    begin
      if Statement then Result := TrueValue else Result := FalseValue;
    end;

    ReplyDelete
  7. Bill Meyer in college I attempted to build a ten digit counter using only nand gates and a clock on a breadboard. Never could get it to work properly. Decided I better stick to software. The digital logic course wasn't a complete loss though. I will sometimes use k-maps to simplify complex nested conditionals when I can't see the forest for the trees.

    ReplyDelete
  8. That's so wrong. Everyone knows that TRUE and FALSE should always be capitalised. And there should be brackets: if not (SomeThing <> TRUE) then ...

    ReplyDelete
  9. Bill Meyer one of the less intuitive refactorings is De Morgans laws, and I've had a number of people comment. After an EE degree hammered them into me I pretty automatically refactor complex boolean logic. Especially the "not a and not b or c" type stuff that seems to infest comms code. 

    Mind you, someone where I work likes to have one condition per statement: "if not a then if not b then ...; if c then ...;" And yes, just copy and paste the code block. Refactoring is made complex by their love of exit instead of else. Really, they just love multiple exit code: "if terminated then exit; if error then exit; if not connected then exit; DisConnect;" (admittedly kinda bearable if it is that that one line).

    ReplyDelete
  10. const
      LIE = Boolean(NOT TRUE);

    ReplyDelete
  11. Moz Le in your coworker's defense those are commonly referred to as guard clauses and are usually easier to reason about than nested if..then..else structures that tries to adhere to the structured programming mantra of one exit per function.

    Like most programming principles there are cases where single exit functions just don't make sense.

    Of course there's always the possibility that a function is juggling too many things and simply needs to be broken up into smaller, more digestible functions.

    ReplyDelete
  12. Heinz Toskano I'm surprised nobody has made the iff() function yet...

    ReplyDelete
  13. Asbjørn Heid they have, that's what the link is about. But it's not a proper ternary operator so it's not especially useful.

    ReplyDelete
  14. Asbjørn Heid I know. Mine was an even worse one.

    ReplyDelete
  15. Asbjørn Heid I know what iff is commonly used to mean, I just don't understand how you would create a ternary operator out of it, or how it would otherwise differ from "if()". Programming languages don't suffer the ambiguities of meat puppet mumblings (they have different ones :)).

    ReplyDelete
  16. I used to use iff() when doing clipper programing, fortunately as soon as start pascal programing never need one again, I remember they where useful for building complex indexes (kind of nightmare to be honest) in times where no relational engines were so popular, and everybody used to do things on xbase.

    ReplyDelete
  17. Moz Le Iff(CondA, CondB, TrueValue, FalseValue), with the TrueValue being returned if CondA xnor CondB is true, else FalseValue. Anyway, was a joke :)

    ReplyDelete
  18. Kenneth Cochran That would have been tedious. The key to it, however, would have been to define modules: flip-flop, decade and modulo six, rather than to approach it as a collection of gates. I remember seeing a digital clock (for video, so HH:MM:SS:FF) which was built in RTL. Nothing but NOR gates on a collection of cards. It filled a 3.5" rack chassis.

    The all-time best single book on digital logic remains Don Lancaster's "TTL Cookbook" from 1974 (still in print.) I had my boss at the time read it. He was a transmitter guy, and to him, logic was relays. He read the book, and while doing so, found a couple of logic errors which made it into print. I offer that as a proof of how clearly the book is written.

    ReplyDelete
  19. Moz Le De Morgan's laws become second nature when you design logic circuits. Or did, when I was doing it. These days, a lot is done in VHDL or other logic languages (which, like software, will be more easily read if you use De Morgan's laws to simplify.)

    ReplyDelete
  20. You can tell some amateur wrote the Androidapi.JNIBridge's IsSetterOrGetter routine as well.

    function IsSetterOrGetter(const Method: TRttiMethod): Boolean;
    var
      Prefix: string;
    begin
      Prefix := Method.Name.SubString(0, DefaultJSetter.Length);
      if (Prefix.CompareText(Prefix, DefaultJSetter) = 0) or
        (Prefix.CompareText(Prefix, DefaultJGetter) = 0) then
        Result := True
      else
        Result := False;
    end;

    ReplyDelete

Post a Comment