How not to program

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Dec 12, 2007.

  1. Good on this guy <http://www.itwire.com/content/view/15745/1141/> for
    publishing his C code for others to see, not so good for not enabling
    comments on that article.

    I can only assume he's trusting the users not to seek out ways to break the
    program. How else can you explain a piece of code that is supposed to
    provide an authenticated gateway to security functions, yet does not guard
    its input against buffer overflows?

    Exercise: how many other things can you find wrong or questionable about
    this code? Below are some I noticed.

    It's full of hard-coded numbers: e.g. 50 bytes for the length of all
    username buffers, 10 bytes for all passwords, 80 bytes for the length of a
    line in the menu-definition file. How hard would it have been to use
    symbolic constants for these sizes?

    The writing to the log file doesn't do any locking to guard against two
    program instances trying to write at the same time. Maybe it would have been
    easier to use syslog?

    The use of type-unsafe "void *" for the "Next" and "Submenu" fields of a
    ScriptNode, when these are clearly just pointers to further ScriptNodes
    (didn't he know how to define recursive types?).

    It would have been a good idea to give a separate name to
    the "/usr/local/menu" directory prefix. That way it would be easier to
    change the locations of the files used by this program.

    Seems like the only kind of loop the guy knows how to write is a "while",
    and he doesn't even know how to use "break". So his loops are accompanied
    by unnecessary dummy assignments and contorted termination checks.

    What's the point of the "iterator" variable in the "Destroy" routine?

    The menu structure is strictly two levels. That means the "Next"
    and "Submenu" fields in a ScriptNode are never both used. Wouldn't it have
    been good to combine both fields and add some kind of "IsSubMenu" flag, so
    that the menu-traversal routines can keep track of whether they're in a
    menu or submenu without it having to be passed as a separate "InSub"
    argument?

    The menu is never redisplayed after an invalid choice. Imagine the user
    doing something like accidentally leaning on the Enter key, until the menu
    display scrolls up and disappears--there is no way to get it back.

    It would have been good to log abnormal exits from child processes. Also
    there is no check for failed calls to "execl" or "system", which is rather
    sloppy--what happens if the referenced executable is not installed, or has
    the wrong permissions, or there's a typo in its name?
     
    Lawrence D'Oliveiro, Dec 12, 2007
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Gordon Guest

    On 2007-12-12, Lawrence D'Oliveiro <_zealand> wrote:
    > Good on this guy <http://www.itwire.com/content/view/15745/1141/> for
    > publishing his C code for others to see, not so good for not enabling
    > comments on that article.


    Or for not asking others to help improve it.

    Yep, pity there are so amny bugs on the three pages of code one sees. Mostly
    ads.
     
    Gordon, Dec 12, 2007
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    Guest

    The comments page works for me; what happened when you tried?

    Some people consider 'break' to be like 'goto' - ie repugnant :)

    Nevertheless, it's terrific that the code is openly displayed, and
    that you can take it, use it and improve upon it - fulfilling the
    admirable ideals of open source software.
     
    , Dec 12, 2007
    #3
  4. Lawrence D'Oliveiro

    Enkidu Guest

    wrote:
    >
    > Some people consider 'break' to be like 'goto' - ie repugnant :)
    >

    They do? Why?

    If you don't like 'goto', consider the old Cobol "ALTER GOTO".

    eg
    ALTER GOTO DEPENDING ON X. Where X is a variable.

    Cheers,

    Cliff

    --

    Have you ever noticed that if something is advertised as 'amusing' or
    'hilarious', it usually isn't?
     
    Enkidu, Dec 12, 2007
    #4
  5. Lawrence D'Oliveiro

    Nik Coughlin Guest

    <> wrote in message
    news:...
    > The comments page works for me; what happened when you tried?
    >
    > Some people consider 'break' to be like 'goto' - ie repugnant :)


    Nothing wrong with 'goto' used judiciously (or 'break' for that matter).

    'goto's don't make spaghetti code, bad coders make spaghetti code.

    Excellent defence of goto by Linus Torvald:

    http://kerneltrap.org/node/553/2131

    "We keep lowering the bar for technical prowess, it seems; if something has
    the potential to be used "wrong", high-minded designers remove the offending
    syntax rather than find or train competent programmers." - Scott Robert Ladd
     
    Nik Coughlin, Dec 12, 2007
    #5
  6. Lawrence D'Oliveiro

    geoff Guest

    Lawrence D'Oliveiro wrote:
    > Good on this guy <http://www.itwire.com/content/view/15745/1141/> for
    > publishing his C code for others to see, not so good for not enabling
    > comments on that article.
    >
    > I can only assume he's trusting the users not to seek out ways to
    > break the program. How else can you explain a piece of code that is
    > supposed to provide an authenticated gateway to security functions,
    > yet does not guard its input against buffer overflows?
    >
    > Exercise: how many other things can you find wrong or questionable
    > about this code? Below are some I noticed.



    Dunna, but like thwe 'open-sorce brigade' nice of him to facilitate the
    distribution of his application with trojans embedded.

    geoff
     
    geoff, Dec 12, 2007
    #6
  7. Lawrence D'Oliveiro

    shane Guest

    geoff did scribble:

    > Lawrence D'Oliveiro wrote:
    >> Good on this guy <http://www.itwire.com/content/view/15745/1141/> for
    >> publishing his C code for others to see, not so good for not enabling
    >> comments on that article.
    >>
    >> I can only assume he's trusting the users not to seek out ways to
    >> break the program. How else can you explain a piece of code that is
    >> supposed to provide an authenticated gateway to security functions,
    >> yet does not guard its input against buffer overflows?
    >>
    >> Exercise: how many other things can you find wrong or questionable
    >> about this code? Below are some I noticed.

    >
    >
    > Dunna, but like thwe 'open-sorce brigade' nice of him to facilitate the
    > distribution of his application with trojans embedded.
    >
    > geoff


    How do you figure that?
    --
    Hardware n: Parts of the computer you can kick
     
    shane, Dec 12, 2007
    #7
  8. Lawrence D'Oliveiro

    Cadae Guest

    "Nik Coughlin" <> wrote in message
    news:fjpjbp$mnr$...
    >
    > <> wrote in message
    > news:...
    >> The comments page works for me; what happened when you tried?
    >>
    >> Some people consider 'break' to be like 'goto' - ie repugnant :)

    >
    > Nothing wrong with 'goto' used judiciously (or 'break' for that matter).
    >
    > 'goto's don't make spaghetti code, bad coders make spaghetti code.
    >
    > Excellent defence of goto by Linus Torvald:
    >
    > http://kerneltrap.org/node/553/2131
    >
    > "We keep lowering the bar for technical prowess, it seems; if something
    > has
    > the potential to be used "wrong", high-minded designers remove the
    > offending
    > syntax rather than find or train competent programmers." - Scott Robert
    > Ladd


    Gotos are bad, not just because of spaghetti code, but because of the hidden
    logic paths they introduce, and the subsequent high probability of
    introducing errors, even for seemingly simple-looking uses.

    This problem with gotos is true also for breaks and returns in the middle of
    a function. Use of gotos, breaks and mid-function returns causes great
    difficulty in working out flow of control. In a program that makes use of
    these, one cannot reliably know what the flow of control is without
    expending a good deal more effort tracing all the paths of control. This is
    far less of a problem with structured code that avoids use of breaks, gotos
    and returns - the indentation in such code gives a highly reliable visual
    indication of flow of control.

    Torvald's defence in the link above is a straw-man argument. He needs to
    re-examine his extremely poor practices.

    PC
     
    Cadae, Dec 12, 2007
    #8
  9. Lawrence D'Oliveiro

    Matty F Guest

    On Dec 13, 9:16 am, Enkidu <> wrote:
    > wrote:
    >
    > > Some people consider 'break' to be like 'goto' - ie repugnant :)

    >
    > They do? Why?
    >
    > If you don't like 'goto', consider the old Cobol "ALTER GOTO".
    >
    > eg
    > ALTER GOTO DEPENDING ON X. Where X is a variable.


    In 1974 I used an ALTER GOTO DEPENDING ON, for a program where speed
    was absolutely essential. That and other nasty code made the program
    10 times faster than the old version. I've been told that the program
    is still in regular use in Australia by a large spare parts company.
     
    Matty F, Dec 13, 2007
    #9
  10. Lawrence D'Oliveiro

    Chris Lim Guest

    On Dec 13, 12:46 pm, "Cadae" <> wrote:
    > Gotos are bad, not just because of spaghetti code, but because of the hidden
    > logic paths they introduce, and the subsequent high probability of
    > introducing errors, even for seemingly simple-looking uses.
    >
    > This problem with gotos is true also for breaks and returns in the middle of
    > a function. Use of gotos, breaks and mid-function returns causes great
    > difficulty in working out flow of control. In a program that makes use of
    > these, one cannot reliably know what the flow of control is without
    > expending a good deal more effort tracing all the paths of control. This is
    > far less of a problem with structured code that avoids use of breaks, gotos
    > and returns - the indentation in such code gives a highly reliable visual
    > indication of flow of control.


    I'd have to disagree with you there. While using gotos, breaks, and
    returns can make it harder to work out what a program does, they can
    sometimes make it easier to understand It all depends on how you use
    them.

    I particularly find gotos and returns useful for error handling, in
    languages that don't support true exception handling. Take the
    following simple TSQL example (apologies if the indenting is screwed
    up):

    ----------------
    INSERT myTable(myColumn) VALUES(@myValue)

    IF @@error != 0
    BEGIN
    RAISERROR('error msg', 16, 1)
    RETURN
    END

    INSERT myTable(myColumn) VALUES(@myValue2)

    IF @@error != 0
    BEGIN
    RAISERROR('error msg', 16, 1)
    RETURN
    END

    INSERT myTable(myColumn) VALUES(@myValue3)

    IF @@error != 0
    BEGIN
    RAISERROR('error msg', 16, 1)
    RETURN
    END

    ...rest of code..
    ----------------

    The equivalent code without using the RETURNs would be:

    ----------------
    INSERT myTable(myColumn) VALUES(@myValue)

    IF @@error != 0
    BEGIN
    RAISERROR('error msg', 16, 1)
    END
    ELSE
    BEGIN
    INSERT myTable(myColumn) VALUES(@myValue2)

    IF @@error != 0
    BEGIN
    RAISERROR('error msg', 16, 1)
    END
    ELSE
    BEGIN
    INSERT myTable(myColumn) VALUES(@myValue3)

    IF @@error != 0
    BEGIN
    RAISERROR('error msg', 16, 1)
    END
    ELSE
    BEGIN
    ...rest of code...
    END
    END
    END
    ----------------

    I find reading the first set of code much easier, because even though
    there are multiple exit points, it's quite clear what's happening.
    With the second set of code, there is only one exit point, but due to
    the large number of nested IF's, it makes if very difficult to follow.
     
    Chris Lim, Dec 13, 2007
    #10
  11. In article <fjpjbp$mnr$>, Nik Coughlin did write:

    > 'goto's don't make spaghetti code, bad coders make spaghetti code.


    Gotos _do_ make spaghetti code.

    One of the things that frequently happens while I'm developing code is
    refactoring. I might see two similar sequences, and try and merge them into
    one common routine called from both places. Or move code out of a routine,
    merge and split sequences, that kind of thing. As a result, blocks of code
    get moved around a lot. But in order to be able to do this easily, the
    blocks have to be strictly nestable: that is, each block is entered at the
    top, and exited at the bottom.

    Things like "break" in C do not violate this, because they occur within the
    block. You can use "goto" in the same restricted way, or you can use it to
    tangle blocks together and make them non-nestable. The latter is bad and
    should be avoided. But then, once you've removed such uses of "goto", why
    not just use "break" for the cases that are left?

    There was something called Nassi-Shneiderman diagrams that we came across as
    undergrads. These were like flowcharts, but more restrictive: the blocks
    had to be strictly nestable. I would say the code I write nowadays would
    fit into these diagrams (if I could be bothered to draw them).
     
    Lawrence D'Oliveiro, Dec 13, 2007
    #11
  12. In article
    <>, Chris
    Lim did write:

    > I particularly find gotos and returns useful for error handling, in
    > languages that don't support true exception handling.


    I wouldn't use gotos and returns, I would use breaks. That way the code
    blocks remain nestable (see my other post on this topic).
     
    Lawrence D'Oliveiro, Dec 13, 2007
    #12
  13. Lawrence D'Oliveiro

    Enkidu Guest

    Matty F wrote:
    > On Dec 13, 9:16 am, Enkidu <> wrote:
    >> wrote:
    >>
    >>> Some people consider 'break' to be like 'goto' - ie repugnant :)

    >> They do? Why?
    >>
    >> If you don't like 'goto', consider the old Cobol "ALTER GOTO".
    >>
    >> eg
    >> ALTER GOTO DEPENDING ON X. Where X is a variable.

    >
    > In 1974 I used an ALTER GOTO DEPENDING ON, for a program where speed
    > was absolutely essential. That and other nasty code made the program
    > 10 times faster than the old version. I've been told that the program
    > is still in regular use in Australia by a large spare parts company.
    >

    COBOL and speed do not go together, even with ALTER GOTOs.

    Cheers,

    Cliff

    --

    Have you ever noticed that if something is advertised as 'amusing' or
    'hilarious', it usually isn't?
     
    Enkidu, Dec 13, 2007
    #13
  14. Lawrence D'Oliveiro

    Murray Symon Guest

    Enkidu wrote:

    > Matty F wrote:
    >> On Dec 13, 9:16 am, Enkidu <> wrote:
    >>> wrote:
    >>>
    >>>> Some people consider 'break' to be like 'goto' - ie repugnant :)
    >>> They do? Why?
    >>>
    >>> If you don't like 'goto', consider the old Cobol "ALTER GOTO".
    >>>
    >>> eg
    >>> ALTER GOTO DEPENDING ON X. Where X is a variable.

    >>
    >> In 1974 I used an ALTER GOTO DEPENDING ON, for a program where speed
    >> was absolutely essential. That and other nasty code made the program
    >> 10 times faster than the old version. I've been told that the program
    >> is still in regular use in Australia by a large spare parts company.
    > >

    > COBOL and speed do not go together, even with ALTER GOTOs.
    >
    > Cheers,
    >
    > Cliff



    Speed is always relative.
     
    Murray Symon, Dec 13, 2007
    #14
  15. Lawrence D'Oliveiro

    Matty F Guest

    Enkidu wrote:
    > Matty F wrote:
    > > On Dec 13, 9:16 am, Enkidu <> wrote:
    > >> wrote:
    > >>
    > >>> Some people consider 'break' to be like 'goto' - ie repugnant :)
    > >> They do? Why?
    > >>
    > >> If you don't like 'goto', consider the old Cobol "ALTER GOTO".
    > >>
    > >> eg
    > >> ALTER GOTO DEPENDING ON X. Where X is a variable.

    > >
    > > In 1974 I used an ALTER GOTO DEPENDING ON, for a program where speed
    > > was absolutely essential. That and other nasty code made the program
    > > 10 times faster than the old version. I've been told that the program
    > > is still in regular use in Australia by a large spare parts company.
    > >

    > COBOL and speed do not go together, even with ALTER GOTOs.


    When all you have is an ICL 1902A and a COBOL compiler, those had to
    be used.
    I knew what code the COBOL compiler generated, and it was near enough
    as good as assembler.
    When it was shifted to an IBM 370, goodness knows how they managed,
    especially with all the 1-bit flags we had on file.
     
    Matty F, Dec 13, 2007
    #15
  16. Lawrence D'Oliveiro

    Allistar Guest

    Chris Lim wrote:

    > On Dec 13, 12:46 pm, "Cadae" <> wrote:
    >> Gotos are bad, not just because of spaghetti code, but because of the
    >> hidden logic paths they introduce, and the subsequent high probability of
    >> introducing errors, even for seemingly simple-looking uses.
    >>
    >> This problem with gotos is true also for breaks and returns in the middle
    >> of a function. Use of gotos, breaks and mid-function returns causes great
    >> difficulty in working out flow of control. In a program that makes use of
    >> these, one cannot reliably know what the flow of control is without
    >> expending a good deal more effort tracing all the paths of control. This
    >> is far less of a problem with structured code that avoids use of breaks,
    >> gotos and returns - the indentation in such code gives a highly reliable
    >> visual indication of flow of control.

    >
    > I'd have to disagree with you there. While using gotos, breaks, and
    > returns can make it harder to work out what a program does, they can
    > sometimes make it easier to understand It all depends on how you use
    > them.
    >
    > I particularly find gotos and returns useful for error handling, in
    > languages that don't support true exception handling. Take the
    > following simple TSQL example (apologies if the indenting is screwed
    > up):
    >
    > ----------------
    > INSERT myTable(myColumn) VALUES(@myValue)
    >
    > IF @@error != 0
    > BEGIN
    > RAISERROR('error msg', 16, 1)
    > RETURN
    > END
    >
    > INSERT myTable(myColumn) VALUES(@myValue2)
    >
    > IF @@error != 0
    > BEGIN
    > RAISERROR('error msg', 16, 1)
    > RETURN
    > END
    >
    > INSERT myTable(myColumn) VALUES(@myValue3)
    >
    > IF @@error != 0
    > BEGIN
    > RAISERROR('error msg', 16, 1)
    > RETURN
    > END
    >
    > ..rest of code..
    > ----------------
    >
    > The equivalent code without using the RETURNs would be:
    >
    > ----------------
    > INSERT myTable(myColumn) VALUES(@myValue)
    >
    > IF @@error != 0
    > BEGIN
    > RAISERROR('error msg', 16, 1)
    > END
    > ELSE
    > BEGIN
    > INSERT myTable(myColumn) VALUES(@myValue2)
    >
    > IF @@error != 0
    > BEGIN
    > RAISERROR('error msg', 16, 1)
    > END
    > ELSE
    > BEGIN
    > INSERT myTable(myColumn) VALUES(@myValue3)
    >
    > IF @@error != 0
    > BEGIN
    > RAISERROR('error msg', 16, 1)
    > END
    > ELSE
    > BEGIN
    > ...rest of code...
    > END
    > END
    > END
    > ----------------
    >
    > I find reading the first set of code much easier, because even though
    > there are multiple exit points, it's quite clear what's happening.
    > With the second set of code, there is only one exit point, but due to
    > the large number of nested IF's, it makes if very difficult to follow.


    Nesting ifs like that is nasty. I've seen code where they're nested so many
    levels deep that you have to scroll just to see that start of the line of
    code. Nasty indeed. And completely unnecessary, even without GOTOs. I'm not
    familiar with TSQL, so excuse the syntax, but you can easily do the above
    without gotos and without nested ifs:

    INSERT myTable(myColumn) VALUES(@myValue)

    IF @@error == 0
    BEGIN
    INSERT myTable(myColumn) VALUES(@myValue2)
    END

    IF @@error == 0
    BEGIN
    INSERT myTable(myColumn) VALUES(@myValue3)
    END

    IF @@error != 0
    BEGIN
    RAISERROR('error msg', 16, 1)
    END

    See - the error is only raised once, there are no gotos and the deepest
    nesting is a single level. Nice, easy to ready, maintainable code.

    I do prefer an language that has exception handlers, which you can wrap in a
    global assert statement so you could change the above to:

    INSERT myTable(myColumn) VALUES(@myValue)
    assert(@@error == 0, "Some error message")

    INSERT myTable(myColumn) VALUES(@myValue2)
    assert(@@error == 0, "Some other error message")

    INSERT myTable(myColumn) VALUES(@myValue3)
    assert(@@error == 0, "Some different error message")

    Which results in much easier to read and maintain code. No nesting at all
    and no gotos.
    --
    A.
     
    Allistar, Dec 13, 2007
    #16
  17. Lawrence D'Oliveiro

    Chris Lim Guest

    On Dec 13, 10:41 pm, Allistar <> wrote:
    > Nesting ifs like that is nasty. I've seen code where they're nested so many
    > levels deep that you have to scroll just to see that start of the line of
    > code. Nasty indeed. And completely unnecessary, even without GOTOs. I'm not
    > familiar with TSQL, so excuse the syntax, but you can easily do the above
    > without gotos and without nested ifs:
    >
    > INSERT myTable(myColumn) VALUES(@myValue)
    >
    > IF @@error == 0
    > BEGIN
    > INSERT myTable(myColumn) VALUES(@myValue2)
    > END
    >
    > IF @@error == 0
    > BEGIN
    > INSERT myTable(myColumn) VALUES(@myValue3)
    > END
    >
    > IF @@error != 0
    > BEGIN
    > RAISERROR('error msg', 16, 1)
    > END
    >
    > See - the error is only raised once, there are no gotos and the deepest
    > nesting is a single level. Nice, easy to ready, maintainable code.


    It's not quite that easy in TSQL. @@error is a global variable that
    only reports the status of the previous statement, so we'd need
    another variable to store the actual error message (in my example I
    used the same error message each time, but in practice each one would
    be different). It would have to be something like this:

    DECLARE @error_msg VARCHAR(255)

    SET @error_msg = ''

    INSERT myTable(myColumn) VALUES(@myValue)

    IF @@error != 0
    SET @error_msg = 'Error 1'

    IF @error_msg = ''
    BEGIN
    INSERT myTable(myColumn) VALUES(@myValue2)

    IF @@error != 0
    SET @error_msg = 'Error 2'
    END

    IF @error_msg = ''
    BEGIN
    INSERT myTable(myColumn) VALUES(@myValue3)

    IF @@error != 0
    SET @error_msg = 'Error 3'
    END

    IF @error_msg != ''
    BEGIN
    RAISERROR(@error_msg, 16, 1)
    END
    ----------------------------------------

    It's not too bad, definitely miles better than the nested IFs, but I
    would still prefer to check for the error and stop the program flow
    immediately rather than continuing to check the error flag all
    throughout the code. It would be all too easy to add some new code in
    the middle of the program and forget about enclosing it in an "IF
    @error_msg != ''
    " block.

    Having said that, I do use the above approach in some situations -
    usually when the error handler is more complicated than a simple
    'raiserror' command and therefore shouldn't be duplicated all
    throughout the code.
     
    Chris Lim, Dec 13, 2007
    #17
  18. Lawrence D'Oliveiro

    Cadae Guest

    "Chris Lim" <> wrote in message
    news:...
    >
    > I particularly find gotos and returns useful for error handling, in
    > languages that don't support true exception handling. Take the
    > following simple TSQL example (apologies if the indenting is screwed
    > up):

    [snip}
    > I find reading the first set of code much easier, because even though
    > there are multiple exit points, it's quite clear what's happening.
    > With the second set of code, there is only one exit point, but due to
    > the large number of nested IF's, it makes if very difficult to follow.


    I find the nested IFs much easier to follow and way more reliable. I can
    instantly see how control is going to flow without having to examine the
    contents of all the IF statements.

    Also, with the nested code, if I need to I can also add a bit of code at the
    end and reliably know that it will be executed regardless of what is in the
    IF statements - this is not true for your first example with the return
    statements imbedded in the IFs.

    PC
     
    Cadae, Dec 13, 2007
    #18
  19. Lawrence D'Oliveiro

    Cadae Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:fjqe21$3en$...
    > In article
    > <>, Chris
    > Lim did write:
    >
    >> I particularly find gotos and returns useful for error handling, in
    >> languages that don't support true exception handling.

    >
    > I wouldn't use gotos and returns, I would use breaks. That way the code
    > blocks remain nestable (see my other post on this topic).


    I agree that breaks are a lesser sin than gotos and returns, and they are
    admittedly required for switch/case statements (tho this is due to poor
    language design).

    However, outside switches, I'd avoid their use as much as possible, as they
    can cause unexpected flow of control problems. Something as small as a
    single line containg a one word 'break' in the middle of a lengthy function
    without any kind of other visual or semantic highlight could cause untold
    misery to a future maintainer. Far better to add a descriptive control
    variable to a loop and make the exit condition explicit in the while( )
    statement at the start of the loop - this makes the exit condition far more
    explicit and meaningful to the casual reader, and makes flow of control
    analysis far simpler.


    PC
     
    Cadae, Dec 13, 2007
    #19
  20. Lawrence D'Oliveiro

    Chris Lim Guest

    On Dec 14, 12:04 am, "Cadae" <> wrote:
    > Also, with the nested code, if I need to I can also add a bit of code at the
    > end and reliably know that it will be executed regardless of what is in the
    > IF statements - this is not true for your first example with the return
    > statements imbedded in the IFs.


    That's interesting. I would've said that's one reason the return
    statements are better. i.e. if I add any code at the end, I know that
    it will never get executed if any serious errors have occurred
    beforehand.

    I just find nested IFs to be a nightmare to read and maintain. The
    above was a trivial example but even with 3 levels of nesting I find
    it starting to get unmanageable. Obviously it's unavoidable sometimes,
    but in the case of handling severe errors like in my example, I prefer
    to get them 'out of the way' as soon as possible and not have to worry
    about them further down in the code. That way anyone reading code at
    line 200 can be assured that the code will not be executing in the
    case of a severe error, without having to check all the nested IF
    conditions to make sure they're right. Not to mention the problem
    Allistair mentioned of having code start off the side of the screen
    due to the number of levels of indentation! A 50" widescreen monitor
    would probably solve that problem though ;-)
     
    Chris Lim, Dec 13, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. fredcromer
    Replies:
    2
    Views:
    542
  2. Robert11
    Replies:
    4
    Views:
    1,474
    El Rossi
    Dec 8, 2004
  3. KDawg44
    Replies:
    1
    Views:
    404
    www.BradReese.Com
    Feb 20, 2007
  4. Jer
    Replies:
    9
    Views:
    376
  5. Replies:
    1
    Views:
    677
    Charlie Russel - MVP
    Apr 30, 2009
Loading...

Share This Page