For New Programmers

Page: 1 2
ID:181373
 
Sep 14 2010, 3:13 pm
Never, ever, ever, ever use usr inside a procedure.. Use src. I see this all to often, I can't take it anymore..
Sep 14 2010, 8:21 pm
What if they know how to use that usr?
Sep 15 2010, 3:34 am
In response to Ripiz
Then they aren't using it there.
Sep 15 2010, 10:04 am
I don't this a rule of thumb, but a useful generalisation.
Sep 15 2010, 10:29 am
In response to Toadfish
A useful generalisation is a rule of thumb, basically (keke, rule of thumb about rules of thumb).
Sep 15 2010, 10:42 am
In response to Stephen001
You're British, Stephen?
And Toadfish... think you forgot a word :P
Sep 15 2010, 10:47 am
In response to Moonlight Memento
Yup, I'm British.
Sep 15 2010, 11:37 am
In response to Toadfish
Toadfish wrote:
I don't this a rule of thumb, but a useful generalisation.

As Stephen mentioned that's a rule of thumb by definition. But it's a little firmer than that; I wouldn't call this a rule of thumb so much as a major guideline. If you find yourself putting usr in a proc, just like with using goto or the : operator, you should strongly question why you're doing it and if there isn't a better way.

There are exceptions to all of these "big three"; I've broken with them at times in my own code, but always with strong justification. Also as one of the few DM programmers who can legitimately call themselves advanced, I'm well aware of where to draw the line on what's a good usage of these and what isn't; since most newbies (and people who don't think they're newbies but basically are) aren't so aware, they should avoid these cases at just about any cost.

Lummox JR
Sep 15 2010, 1:39 pm
In response to Lummox JR
I've found that the colon operator is especially useful for getting the value of an object without actually loading an object. You can retrieve the initial value of a variable or get some constant or static data. And it's the only use I've found for it so far.

var/initialValue = /MyDatum:variable
Sep 15 2010, 7:28 pm
In response to Dipstyx
That's actually a different function of the : operator. static variables =D
Sep 16 2010, 11:32 am (Edited by moderator on Sep 20 2010, 6:04 pm)
In response to Nadrew
Why are these undocumented features NEVER documented or noted anywhere? Knowing this would be tremendously useful.
Sep 16 2010, 12:22 pm (Edited by moderator on Sep 20 2010, 6:05 pm)
In response to Popisfizzy
Popisfizzy wrote:
Why are these undocumented features NEVER documented or noted anywhere?

Hrm?
Sep 16 2010, 12:23 pm
In response to Airjoe
That was just added today. :|
Sep 16 2010, 12:24 pm (Edited on Sep 16 2010, 12:32 pm)
In response to Popisfizzy
<font size=5 style="color:#000;background:#fff">ಠ_ಠ </font>
Sep 16 2010, 3:50 pm
In response to Popisfizzy
And it doesn't compile.

mob
    var
        myVar=10
    proc
        Initial_Value_Of_myVar()
            return /mob:myVar


Gives this error:

code.dm:7:error: return/mob/:/myVar: invalid expression
Sep 16 2010, 7:52 pm
In response to Forum_account
Well, let alone the fact that that example makes no sense entirely.
Sep 16 2010, 8:04 pm
In response to Lummox JR
That whole sentence was botched....

I am in agreement with what you say, and I will add, that while a newbie programmer might sometimes find it difficult to detect the fine line between "fair use" and botched code, by thinking of something as a restriction rather than a rule of thumb, we are always losing certain properties of a language. I support teaching such a newbie to treat the big three as "restricted" aspects of DM, but the same thing is of course not ideal for a more advanced user. The simplistic way they taught us mathematics as we passed our years in elementary school was suitable for that environment and our intellect at the time, but a middle schooler, and a high schooler still, need a deeper, more foundational approach.
Sep 16 2010, 11:12 pm
In response to Forum_account
Doesn't work quite as you'd expect it, due to how the compiler uses the look-up and look-down operators (: and .) it goofs up and spits the wrong error out. To get around it you have to define a variable for the compiler to catch on to. It doesn't have to be initialized. There's also another compiler goof that makes it not consider said variable used. So you have to workaround that too. You also need to use the undocumented (and 100% legacy) 'static' keyword.

When it comes down to it, static variables were an idea that never really took off, they worked as expected at one point, but other compiler changes broke them somewhere down the line.

A functional example of static variables with all of the hacks and workarounds to make it compile without errors or warnings.
mob
    var
        static/test = 10 // Without the 'static' keyword, the TestMe() verb would spit out a 'cannot read null.test' runtime error.
    
    verb
        TestMe()
            var/mob/M // Notice how you don't actually have to create the mob with new(), the compiler USED to work with just /mob:[variable], not anymore.
            M = M // Workaround for the compiler's mis-warning of 'variable defined but not used'
            usr << M:test // Outputs 10
Sep 17 2010, 3:28 am
In response to Nadrew
With how shoddy the support is for this, maybe it's better that we leave it undocumented =)
Sep 17 2010, 5:10 am
In response to Toadfish
Toadfish wrote:
I am in agreement with what you say, and I will add, that while a newbie programmer might sometimes find it difficult to detect the fine line between "fair use" and botched code, by thinking of something as a restriction rather than a rule of thumb, we are always losing certain properties of a language. I support teaching such a newbie to treat the big three as "restricted" aspects of DM, but the same thing is of course not ideal for a more advanced user. The simplistic way they taught us mathematics as we passed our years in elementary school was suitable for that environment and our intellect at the time, but a middle schooler, and a high schooler still, need a deeper, more foundational approach.

Well note I said "major guideline" and not "restricted" for that reason. I tell newbies to avoid these three things at all costs in the hopes that if one of them is ever pushing into more advanced/intermediate territory, they'll have the good sense to ask on the forums how to work around whatever design quandary they're in.

The problem is, basically most newbies are not graduating to intermediate code. To improve as a programmer they have to 1) challenge themselves, 2) communicate with other programmers, and 3) learn from experience. I've seen many manage any one of those without ever trying the other two. I've seen some who were obviously never capable of learning at all, who made the same mistakes over and over again with such predictability that they had no hope--and some of them regarded themselves as good programmers.

Lummox JR

Lummox JR
Page: 1 2