You're Wrong.
There's a certain mentality that I've noticed a lot of users within our ranks have. This is mostly common to inexperienced programmers who have managed to throw out what can be considered barely passable games and who now suddenly think they're top dog because they've done so.
The mentality I'm referring too is pretty much summed up in the title of this post, if at any time recently you've said: "it works, so I'm doing it right", "you do it differently than I do, that doesn't make you right" or any variation there of, then chances are you fall into this category. And this post is aimed directly between your eyes.
You see, there are many ways to do lots of things. And anyone with any life experience can tell you, even though they work, it doesn't make them safe, advisable and least of all, correct.
For a quick analogy: I can drive the wrong way down a motorway. By the logic of those targeted at this post, I'm doing it right, because I'm still getting to my desired destination. By the logic of all other experienced motorists not on any form of narcotic, I'm being an absolute tool by driving recklessly and putting the lives of other people in my obviously foolish hands.
In a real life scenario, I'd probably get my license revoked for dangerous driving and there might also be some jail time depending on my reaction towards the judge. If programming required a license, everyone this post is targeted at would by theory, also get their licenses revoked and no longer be allowed to make games. And I dare say a few of you would also be looking at jail time for your reactions towards those who attempt to help you by telling you you're doing it wrong.
Now lets move onto a code example. One Garthor corrected me on recently; just to show that even I am not infallible when it comes to programming. You can view the thread here. Please note my reaction, or lack there of, as that is pretty much what this entire post is about. Instead of arguing that I'm correct because it works, I conferred with my colleagues and then accepted the words of a superior programmer silently, and am now no longer making that mistake.
Wrong:
#define SECOND 10
#define MINUTE (SECOND * 60)
#define HOUR (MINUTE * 60)
#define DAY (HOUR * 24)
client
proc
SaveProc()
//Some random save proc for clients.
proc
recursive_save_or_something()
for(var/client/C) C.SaveProc()
sleep(HOUR)
.()
Better:
#define SECOND 10
#define MINUTE (SECOND * 60)
#define HOUR (MINUTE * 60)
#define DAY (HOUR * 24)
client
proc
SaveProc()
//Some random save proc for clients.
proc
recursive_save_or_something()
while(TRUE)
for(var/client/C) C.SaveProc()
sleep(HOUR)
(Come to think of it, that proc should probably have a set background = TRUE in it.)
As you can see, my original example still worked, but that didn't mean I was right, at the end of the line, a place you can't reach in two minute testing sessions of new features, I'd have eventually crashed my game entirely. And we all know what that means.
I'd have gone running to the developer forums crying: "why oh why sweet merciful gods of programming does my game fail so?" They would have eventually given me an answer if anyone cared enough to stick around long enough to debug it, and I'd have been left with a lot of reworking to do, simply because I never learned my lesson and undoubtedly made lots more of these mistakes.
Now let's take a trip down memory lane, way back in 2005 when I was a way more inexperienced programmer than I am now and dared to ask the question a lot of you refuse to ask and stick to your "I'm right" mentality: Why does which way matter?. This thread should explain to you why we go out of our way to tell you why your examples are incorrect. Don't let the attitude a lot of us have fool you, our goal is to help you. But we're not certified teachers and a lot of us don't have the patience to hold your hand through everything. Which is why we often link to reference material that we hope you will read and understand.
I hope this article has been enlightening for you. And I also hope that it's also opened a few peoples eyes. You don't learn by getting it right first time every time, but if you're doing it wrong, you will learn by simply asking the right questions and learning from what better programmers have to say. If I had not listened to Lummox JR, Wizkidd0123, Xooxer, Crispy, YMIHere or Garthor, I'd still be making horrendous mistakes that would ultimately cost me the stability of my game.
That's not to say I'm still not making mistakes, as humans, we are doomed to forever make mistakes. Hell, the previous example I used in this post probably has a better way to go about it (ten points for someone who comes up with a working theory as to why). Which is precisely what Design Philosophy is for: Asking people if how you're doing something is right, and whether or not there's a better method to go about it.
If this post reminds you of yourself, I also recommend reading How to Fail at Game Programming by Deadron. Well worth it, if only for the entertainment value.
Seemed to work just fine for making a turf in which the player who entered it would be teleported to the space station. However, when he tried to use Enter() in a similar manner to to coordinate various functions on the space station, he was boggled that he suddenly wasn't able to move.
The problem, of course, was that he needed to be using Entered(), not Enter(). Enter() was run at about the same time as Entered(), but the job of Enter() is to return true if you're allowed to enter the proc. When he override Enter() without returning true, all of a sudden he wasn't allowed to move anymore. The reason why he got away with it before was because the function of the Enter() actually moved the user.
He went on to make a similar mistake by trying to use typesof() instead of istype() to perform verification that something was of a certain type. Of course, typesof() returns a list of derived types (as long as at least one of the args existed otherwise it would return null) so because his arg would include a known type, his if statement was always being evaluated as true. Seemed to work, sure, right up until something came along that wasn't supposed to be true.
The bottom line is basically this: you need to know what your code actually does, in other words, exactly what you're telling the computer to do. Computers may be fast at computing, but they're dumb as a sack of rocks (pounded into silicon and veined with circuitry). They'll do exactly whatever stupid thing you've told them to do, Sorceror's Apprentice style, no more, no less. Whenever I see a fantasy scenario where the computer takes over mankind (e.g. Terminator, The Matrix) I can only smugly acknowledge that it would mean some dumb coder failed to pay attention to what they were coding.
Understanding exactly what every little line of code you've written does is not implicit knowledge, and we should forgive the newbies for not knowing this. A lot of this comes with experience. However, it'll come a lot faster if you regularly consult the BYOND DM help, resources, and forums to get a better understanding.
Put another way, when you begin programming, it's all you can do to simply focus on how to hammer the individual nails into place. When you're better at programming, the hammering of nails can can be done subconciously, and your attention should instead be on how to assemble entire rooms. When you've mastered programming, you'll be able to visualize the entire palace and its scheme in the greater universe.