How To/Not To : BYOND.

Page: 1 2
Sep 22 2010, 12:40 pm
Besides the variable names, which DivineTraveller commented on for pretty much the same reason I don't necessarily agree with it, great post! I think variables should be legible, but I don't think the var_ there is at all necessary. Anybody with a brain should be able to figure out that "src.brain_power++" is talking about a variable without the var_ being there.

It's always nice to see posts like this, though! I can tell you put some effort into it.

Too much writing makes the code look bad to other people. Too little writing (too many abbreviations; difficult to read) makes the code look bad to other people. There's a happy medium, I think.
Sep 22 2010, 1:10 pm (Edited on Sep 22 2010, 1:20 pm)
Fugsnarf wrote:
... Anybody with a brain should be able to figure out that "src.brain_power++" is talking about a variable without the var_ being there.

I accounted for the people who don't directly associate what they are working with. For example :

mob/proc/gainOneHealth()
myHealth += 1

instead of what I prefer :

mob/proc/gainOneHealth()
src.myHealth += 1

Although you and DT are truly correct that it's not required. It's more of an emphasis to name data more precisely.
I honestly don't use the "type_" but a very few amount of people have benefited from it's usage.
Sep 22 2010, 1:24 pm
Using the "var_" prefix to denote that something is a variable is a terrible idea. In this code try to identify the variable and the proc:

something += 5
whatever(9,3)


You don't need "var_" and "proc_" prefixes.

You might want to read up on Hungarian Notation. The purpose of the notation is to tell the programmer something about the variable that isn't already obvious*. In DM this can be useful because strings and numbers are both vars. You can use naming conventions to keep things straight:

* This is also the purpose of comments. If you have a variable called "maxHealth" a comment that says "this is the player's max health" doesn't tell you anything that the variable's name doesn't.

mob
    var
        strStatus


The str- prefix tells you that the variable should contain a string.

This isn't as necessary for object references because the type is specified when you define the variable. If there are any doubts about what the variable represents you can check the definition.
Sep 22 2010, 2:52 pm
So to sum it up on the variable terms, you want us to do it Visual Basic style? I hate Visual Basic.
Sep 22 2010, 2:55 pm
OrangeWeapons wrote:
So to sum it up on the variable terms, you want us to do it Visual Basic style? I hate Visual Basic.

I'm not familiar with Visual Basic, you'll have to be more clear.

What Forum_account, DT and Fug said is perfectly fine. It's sometimes known as the "hump-back" method.

Ex; maximumHealth, totalInventorySlots.
Sep 22 2010, 2:58 pm
Maximus_Alex2003 wrote:
What Forum_account, DT and Fug said is perfectly fine. It's sometimes known as the "hump-back" method.

There's a big difference between Camel Case and putting prefixes on identifiers.

I don't prefer Camel Case but there's really nothing wrong with it. Prefixing variables with var- is unnecessary whether you prefer capitalization or underscores to separate words.
Sep 22 2010, 3:00 pm
Forum_account wrote:
There's a big difference between Camel Case and putting prefixes on identifiers.

I don't prefer Camel Case but there's really nothing wrong with it. Prefixing variables with var- is unnecessary whether you prefer capitalization or underscores to separate words.

I think we've already established this...
Sep 22 2010, 3:02 pm
Maximus_Alex2003 wrote:
I think we've already established this...

Then I don't know why you said this:

What Forum_account, DT and Fug said is perfectly fine. It's sometimes known as the "hump-back" method.

My first comment had nothing to do with the "hump-back" method.
Sep 22 2010, 3:14 pm
Sorry, I wasn't clear enough.

We have already established that "type_" prefixes are " terrible ".
Sep 22 2010, 3:54 pm
Concerning the prefixing of variables, procs, verbs etc. This is entirely personal preference. Strict naming guidelines are only necessary if you're releasing code to the public. And even then, there's very little if any reason to prefix variables with the word "var".

Stuffing any variables that would be common enough to need a prefix would probably be better suited in a datum anyhow. As for datum naming, if you're releasing a library, it's at best safer to name your datum max_datum or tib_datum etc. And that is purely for preventing overriding a datum someone else may have already written.
Sep 22 2010, 5:10 pm (Edited on Sep 22 2010, 5:21 pm)
For fun, I'll throw in my style preference which I know most people wouldn't go for but I've really grown fond of it.

In my case, I append the owner (m_) of the variable out front. For the most part, this helps me distinguish between global and mob variables. I do not append anything to local variables which makes those easy to identify as well. Then I add the type identifier (_i) which helps me keep tabs of what a variable is. I use Hungarian notation starting with the type which works out nicely. When it comes to datum methods, I do not append an owner (Mob_) because the owner is the datum object itself.

:) So there you have it...

var
{
    g_iLoginCount = 0;
    g_sIPAddress = "1.1.1.1";
}
mob
{
    var
    {
        m_iHealth; // mob integer
        m_sCustomTagNam; // mob string 
        datum/car/m_dCar; // mob datum
    }
    proc
    {
        //
        // Comments for block of code go here like this
        // Next line goes here
        //
        Mob_DisplayStats()
        {
            //
            // If we have at least 1 user, kick start the tick
            // Normally, I would never do this... 
            //
            if (g_iLoginCount)
            {
                Proc_WorldTick(m_iHealth); // As example proc call
            }
        }
    }
}
proc
{
    Proc_WorldTick(var/iHealth)
    {
        ...
    }
}


and for what its worth, the events which keep causing the comment window to appear disabled when you move your mouse away is really annoying. I also can't read my code example due to the filter effects applied.
Sep 22 2010, 5:22 pm
If you have a prefix to specify the type of a variable (which itself is rather unnecessary) you don't need the prefix on all of its vars/procs.

var/mob/mPlayer = something
mPlayer.Mob_DisplayStats()


The m- prefix on the mPlayer variable tells us that the variable is a mob. The "Mob_" prefix on the proc name is redundant and can get excessive for deeper object hierarchies.

Prefixes should be used to tell you something that is not obvious. A better usage would be for return types:

mob
    proc
        obj_item_FindItem()
            for(var/obj/item/i in view(1,src))
                return i


The "obj_item_" prefix tells you that the return value is of type /obj/item. To find this out you'd have to find the proc and look through the code to discover its return type. With more complex functions this becomes non-trivial.
Sep 22 2010, 5:37 pm
You need to lose the drop shadow on code blocks and raise it to at least 10px.
Nov 11 2010, 2:02 pm (Edited on Nov 11 2010, 4:51 pm)
Testing something with my CSS...
#define
//  comment line
proc
'file'
"string"
Page: 1 2