What exactly do you mean by "Robust Code". in Design Philosophy

Page: 1 2
ID:265518
 
Nov 23 2005, 8:59 am
When I program, I try to program the very best I can, and make sure to fix any problems before they every happen.
What exactly do you mean by programming "Robustly"?
#1 Nov 23 2005, 9:06 am
Well...
  • Alot of usr abuse
  • Useless if() statements
  • Using the 'goto' function
  • Not using while correctly
  • I'm forgetting some more.
#2 Nov 23 2005, 9:09 am
I believe that it generally refers to writing code that is as "sturdy" as possible by using the best programming practices... Not necessarily fixing problems, but programming from the ground up in a way that will not allow any to even arise...

An example is with the usr "debate"... Yes, usr will work in many cases, and if one is lucky, one could get away with using it, and never seeing any problems... However, it is not 100% foolproof, and there are better alternatives, so one's code would be more robust without it...
#3 Nov 23 2005, 9:11 am
In response to SuperSaiyanGokuX (#2)
Exactly, that is why I never use it.
#4 Nov 23 2005, 10:02 am
In response to Xeal (#1)
Actualy, it is common that the 'robust' code ends up with the useless statements that do currently unessecary safety checks, but of course not always with if statements.

#5 Nov 23 2005, 10:20 am
In response to Xeal (#1)
Xeal wrote:
Well...
  • Alot of usr abuse
  • Useless if() statements
  • Using the 'goto' function
  • Not using while correctly
  • I'm forgetting some more.

    Those are examples of brittle code, not robust. Although "useless if() statements" probably doesn't belong in that list. And goto does have rare uses, so that should really be rephrased.

    Lummox JR
    • #6 Nov 23 2005, 10:21 am
    The topic of robust programming is explained in some depth here:

    Dream Tutor: Bulletproof Code

    Lummox JR
    #7 Nov 23 2005, 10:55 am
    In response to Lummox JR (#6)
    The usr thing is actually something not to be avoided, but to be understood. It has to be used sometimes, like in verbs, but should be stayed away from if you don't know what you want it to do.
    #8 Nov 23 2005, 11:11 am
    In response to Lummox JR (#6)
    Lummox JR wrote:
    The topic of robust programming is explained in some depth here:

    Dream Tutor: Bulletproof Code

    Lummox JR


    I just learned alot from that article. Thanks lumm.
    #9 Nov 23 2005, 11:14 am
    In response to Lou (#7)
    Lou wrote:
    The usr thing is actually something not to be avoided, but to be understood. It has to be used sometimes, like in verbs, but should be stayed away from if you don't know what you want it to do.

    Verbs don't necessarily need usr; if you're using set src, then you actually do need it, but oftentimes even then the best use of it is simply to pass it along to a proc that doesn't directly use usr. But otherwise, src is going to equal usr anyhow, and src is much more predictable (although it's still often a good idea to move your actual functionality to a proc that can be called on anything, and just use the verb to call the proc with src).
    #10 Nov 23 2005, 11:19 am
    In response to Lou (#7)
    Lou wrote:
    The usr thing is actually something not to be avoided, but to be understood. It has to be used sometimes, like in verbs, but should be stayed away from if you don't know what you want it to do.

    Putting usr in a verb is not usr abuse; it belongs there. Likewise there's no problem with putting it in certain pseudo-verbs like atom/Click() or mob/Stat(). Putting usr in a regular proc is usr abuse.

    Lummox JR
    #11 Nov 23 2005, 8:08 pm
    In response to Leftley (#9)
    I personally mostly use src everywhere unless the specific function need usr, like in atom/Click() (which I rarely use because of client/Click() =P). I do this generally because verbs are just procs which are called by clicking/typing the verb. I also generally don't use that <code>set src</code> settings in verbs because I prefer interacting with stuff from the mob class and the object class being the argument rather than vice versa.

    ~~> Unknown Person
    #12 Nov 26 2005, 12:38 am
    Robust code = Code that won't just fall apart and give you odd bugs if you screw up a proc call or something like that, but fails predictably and in a way that makes tracing those screw ups easy. Generally modular, and generally suffers from far less Heisenbugs then code that isn't robust.

    Heisenbug = A bug that you can't seem to reproduce, and that turns up randomly for no aparrent reason.
    #13 Nov 26 2005, 9:50 am
    In response to Jp (#12)
    Jp wrote:
    Robust code = Code that won't just fall apart and give you odd bugs if you screw up a proc call or something like that, but fails predictably and in a way that makes tracing those screw ups easy. Generally modular, and generally suffers from far less Heisenbugs then code that isn't robust.

    Heisenbug = A bug that you can't seem to reproduce, and that turns up randomly for no aparrent reason.

    Robust code also suffers less Hindenbugs. Oh the humanity!

    Lummox JR
    #14 Nov 26 2005, 10:37 am
    In response to Jp (#12)
    Heisenbug = A bug that you can't seem to reproduce, and that turns up randomly for no aparrent reason.

    I hate the ones which dissapear for no apparent reason when you get around to setting up a bunch of code to help debug the problem :P.
    #15 Nov 26 2005, 6:19 pm
    In response to Theodis (#14)
    ROFL.

    Man, being a programmer will suck once they start manufacturing quantum computers...
    #16 Nov 26 2005, 7:17 pm
    In response to Crispy (#15)
    Not really. We can just blame the hardware. :P
    #17 Nov 27 2005, 1:12 am
    In response to Lummox JR (#5)
    Boing! Boing! Boing!

    That's what BASIC does wrong!

    K!
    A!
    N!
    G!
    E!
    R!
    O!
    O!
    code!
    #18 Nov 27 2005, 11:13 am
    In response to Lummox JR (#13)
    Robust code also suffers less Hindenbugs. Oh the humanity!

    "If it's not on fire, it's a software problem." --Matt C. Burch
    #19 Nov 27 2005, 1:08 pm
    In response to Lummox JR (#10)
    What about objects and turfs with verbs attached to them? For something to happen to the player, or to display data to the player, you need to use usr because src is the atom containing the verb.
    Page: 1 2