About Map Cloning in Map Cloning

ID:304767
 
Feb 13 2012, 12:00 am
Map Cloning by PopLava
Cloning maps with SwapMaps made easy
0 fans · Created Feb 13 2012
This example shows how easy it is to clone maps with the SwapMaps library. You can dynamically generate maps from templates, randomize them, delete them, and teleport between them.

2/20/2012 - v1.1
- Minor tweaks to clean up source code per feedback.
#1 Feb 15 2012, 7:56 am
1. There's an awful lot of code for something so simple. The curly braces certainly don't help with that.

2. It would have been nice to have a stat panel showing the current set of maps. Maybe list each z level that exists and indicate which one you're on.

3. You use a lot of hardcoded values, like 10 as being the size of the map.

4. For how you're using it, prob(50) makes more intuitive sense than than pick(0,1).

5. The Mob_- and Proc_- prefixes are wildly unncessary.

6. Some of your variable names are overly elaborate, like "iUserProvidedZLevel". For a local variable in a three line proc a one-letter name would have been sufficient. There's also "listOfTurfsInView" in the Proc_ResetToGrass proc which is overly elaborate and not even used =)

7. Your usage of whitespace isn't consistent. Sometimes you put spaces after commas (ex: "locate(1, 1, m.z1)") and sometimes you don't (ex: "block(locate(1,1,z),locate(10,10,z))").

8. You usage of semicolons is not very consistent. If it's a habit left over from another language they'd be more consistent.

It's great that you've developed your own programming style but it's often detrimental. If you think it works for your personal projects that's fine, but it shouldn't get in the way of putting together a decent demo.
#2 Feb 19 2012, 8:49 pm
In response to Forum_account (#1)
Forum_account wrote:
3. You use a lot of hardcoded values, like 10 as being the size of the map.

Debatable in terms of trading off simplicity for something more dynamic.

4. For how you're using it, prob(50) makes more intuitive sense than than pick(0,1).

heh, if you say so.

5. The Mob_- and Proc_- prefixes are wildly unncessary.

Your comments about my syntax choices are equally as unnecessary.

6. Some of your variable names are overly elaborate, like "iUserProvidedZLevel". For a local variable in a three line proc a one-letter name would have been sufficient. There's also "listOfTurfsInView" in the Proc_ResetToGrass proc which is overly elaborate and not even used =)

Again. My variable naming choices seems like such a petty thing to bring up. Your also mistaken about the variable usage.

7. Your usage of whitespace isn't consistent. Sometimes you put spaces after commas (ex: "locate(1, 1, m.z1)") and sometimes you don't (ex: "block(locate(1,1,z),locate(10,10,z))").

Thanks for pointing out the difference in my whitespace. It's truly going to make a huge difference in the quality of my code. I'll be reminded of your quality feedback every time I push the space-bar.

8. You usage of semicolons is not very consistent. If it's a habit left over from another language they'd be more consistent.

This is more of whatever it is your trying to get across... not sure what though. If I even have to comment on it... I'm just getting lazy about fixing the inconsistency since it's trivial and meaningless much like this "feedback".

Let's not call it feedback though. This is like empty whining without rhyme or reason. Like your fishing for something.

It's great that you've developed your own programming style

Thanks!




#3 Feb 20 2012, 5:24 am
In response to PopLava (#2)
There's nothing wrong with the style that you've used but it's quite different from what most DM programmers are used to seeing. Most people will be thrown off by the code and won't be able to make sense of it. While a lot of my comments seem superficial, the details that are important for educational demos like this are often extremely superficial. You can turn a good demo into a bad one (or vice versa) by changing variable names and whitespace. It's not all about function.

You also went to great lengths for some superficial details (variable names, proc name prefixes, curly braces, semicolons, etc.), so you clearly value how code looks and not just how it functions.

PopLava wrote:
Your also mistaken about the variable usage.

Here's the code:

    Proc_ResetToGrass(var/listOfTurfsInView)
    {
        for (var/turf/t in view(10))
        {
            t.icon_state = "grass";
        }
    }


The listOfTurfsInView argument isn't used at all. It's also a misleading name since the list doesn't really have to be a list of turfs in view. The proc could reset the icon_state for any list of turfs.
#4 Feb 20 2012, 8:31 am (Edited on Feb 20 2012, 8:42 am)
In response to Forum_account (#1)
Forum_account wrote:
1. There's an awful lot of code for something so simple. The curly braces certainly don't help with that.

I'm gonna have to agree here. You should most certainly remove the curly braces. If you think you're emphasizing code-readability, especially in a language like DM(which is 'weakly-typed'), you have made a big mistake.

5. The Mob_- and Proc_- prefixes are wildly unncessary.

A style of prefixing variables/functions are completely up to a programmer; he/she pursue a style that they're comfortable with. Though the Proc_- prefix is nonsensical in this case because you are, after all, creating a procedure.

6. Some of your variable names are overly elaborate, like "iUserProvidedZLevel". For a local variable in a three line proc a one-letter name would have been sufficient. There's also "listOfTurfsInView" in the Proc_ResetToGrass proc which is overly elaborate and not even used =)

http://en.wikipedia.org/wiki/Naming_convention_(programming)


#5 Feb 20 2012, 10:05 am
awkward prefixing and naming is counter intuitive if you're looking for other people to read and comprehend your code.
#6 Feb 20 2012, 10:57 am (Edited on Feb 20 2012, 11:27 am)
In response to Forum_account (#3)
Forum_account wrote:
There's nothing wrong with the style that you've used but it's quite different from what most DM programmers are used to seeing. Most people will be thrown off by the code and won't be able to make sense of it.

Pure speculation.

While a lot of my comments seem superficial, the details that are important for educational demos like this are often extremely superficial. You can turn a good demo into a bad one (or vice versa) by changing variable names and whitespace. It's not all about function.

Or... you could turn a good example into a better one.

You also went to great lengths for some superficial details (variable names, proc name prefixes, curly braces, semicolons, etc.), so you clearly value how code looks and not just how it functions.

Not great lengths and it's mostly just requirements of other languages and applied standards through code reviews. It's far easier to apply the similarities than to constantly make mistakes across my environments. With that said, I believe my layout choices make the code far easier to read when compared with the BYOND preferred syntax.

PopLava wrote:
Your also mistaken about the variable usage.

Here's the code:

>   Proc_ResetToGrass(var/listOfTurfsInView)
>   {
>       for (var/turf/t in view(10))
>       {
>           t.icon_state = "grass";
>       }
>   }
>


The listOfTurfsInView argument isn't used at all. It's also a misleading name since the list doesn't really have to be a list of turfs in view. The proc could reset the icon_state for any list of turfs.

My local copy utilizes the variable so I must have uploaded a different build somehow. Either way, thanks for pointing this out.
#7 Feb 20 2012, 11:23 am
In response to Urias (#4)
Urias wrote:
Forum_account wrote:
1. There's an awful lot of code for something so simple. The curly braces certainly don't help with that.

I'm gonna have to agree here. You should most certainly remove the curly braces. If you think you're emphasizing code-readability, especially in a language like DM(which is 'weakly-typed'), you have made a big mistake.

Perhaps you could elaborate on my big mistake?

5. The Mob_- and Proc_- prefixes are wildly unncessary.

A style of prefixing variables/functions are completely up to a programmer; he/she pursue a style that they're comfortable with. Though the Proc_- prefix is nonsensical in this case because you are, after all, creating a procedure.

I find that these prefixes enable me to fly through the code via the scroll bar to locate groups of things a lot faster than not having them. I also utilize this prefixing as a poor mans way of type-safety. It makes it obvious what context I'm currently in at all times (without scrolling). All in all, I make far fewer mistakes when moving code around because I never lose sight of the intended context.


6. Some of your variable names are overly elaborate, like "iUserProvidedZLevel". For a local variable in a three line proc a one-letter name would have been sufficient. There's also "listOfTurfsInView" in the Proc_ResetToGrass proc which is overly elaborate and not even used =)

http://en.wikipedia.org/wiki/Naming_convention_(programming)

Sure... I have an elaborate variable in there which probably was converted from a global var or something along those lines. Although, I'm not afraid to provide meaningful variable names because it bakes my original intention into the code.

I can freely move blocks of code around without losing sight of a variables original meaning and I reduce my chances for wrongly using it.

When I come back to the code a couple months or years later, reading my code provides you with a self-documented history of intention.
#8 Feb 20 2012, 11:26 am
In response to Yut Put (#5)
Yut Put wrote:
awkward prefixing and naming is counter intuitive if you're looking for other people to read and comprehend your code.

It's not so awkward that people can't easily figure it out. If I were to go and grab a sampling of function names from random examples across this site, I'm fairly confident that my function names are far better than most (prefix or no).

Regardless, it's a style preference and therefore should not be on the table for debate unless I requested it.
#9 Feb 20 2012, 12:28 pm
In response to PopLava (#7)
PopLava wrote:
Perhaps you could elaborate on my big mistake?

I apologize. It wasn't a big mistake, but a lot of DM programmers might find it a bit redundant, especially since a lot of them aren't used to the exposure of other languages.

I find that these prefixes enable me to fly through the code via the scroll bar to locate groups of things a lot faster than not having them. I also utilize this prefixing as a poor mans way of type-safety. It makes it obvious what context I'm currently in at all times (without scrolling). All in all, I make far fewer mistakes when moving code around because I never lose sight of the intended context.

That's fine. I didn't say your prefixing style was wrong, everyone has their own style of formatting their code.