What I get a tad ticked off by is the "secret" usr abuses, like input() and view(). I've spent ages trying to debug some code to realise that because those functions default to usr, it was usr abuse that was causing the problem. :p
| |
Elation wrote:
Because then you can call it any time for a variety of reasons. Say you have an attack verb- but later on in the game you realise you want to have an option so players wil automatically attack back. Then just calling the right attack proc, the same one the verb calls, is a lot easier and easier to understand later. Having a bunch of verbs scattered about the place with various functions is *confusing*. You can call verbs as normal functions. mob/verb disarm is a verb and still works normally when called by disarm. That's why we write segmented code these days, with seperate functions! Back in the days when I was first learning computer programming, segmented code was undeard of. And seperate functions? Why, we would just use goto or gosub to skip to another line which was placed out of the way to order our code. And we had to pass data upload both ways. No duh? People wouldn't follow his advice if he was a dumbass who wrote crappy code that broke down at every hurdle. People follow his advice because *he gives the best advice*. I wouldn't say he always gives the best advice, but his advice is definately worth its weight in silver. He writes articles on why usr abuse is a bad thing. He write s articles on how to write good, proper code. Oh, it isn't? Or is it... I don't know how you can question something that is so intrinsically good. <=| It is good to question things as long as you will look into it and figure out the truth for yourself. Maybe he will realise the headaches he is putting himself through and reform to elegance. For the record, I rarely use usr, not even in verbs. I do not find it necessary, or even beneficial or easier for that matter. About the only place you will ever see me use it on occasion is in Click, but even then it is not even absolutely necessary. | |
Yah. Click and procs like that work pretty much like verbs anyway.
Back in the days when I was first learning computer programming, segmented code was undeard of. And seperate functions? Why, we would just use goto or gosub to skip to another line which was placed out of the way to order our code. And we had to pass data upload both ways. Yeah, my mum told me she took a very basic programming course in university, or something. She told me you had to number each line of code. Gross. :p | |
Justin Knight wrote:
If I was replying to the topic in general, I would say this: Although there are exceptions to the rule, it's important to note that the reason for repeating the mantra is to keep newbies from making the same stupid mistakes over and over and over. The Big Three (usr in procs, the colon operator, and goto) are not to be touched by newbies, who will simply not encounter situations where they actually need to be used. All of these are abused as crutches in place of robust code, because newbies don't know the way to do it right. Rather than asking, rather than trying, they do it wrong first and then wonder why subtle bugs creep into their program. So basically, any exceptions will never cross a newbie's path; it's foolish to bother complicating the issue for them. If they get the idea that some things are to be avoided like the Plague, they'll learn better code practice by following the rule rather than seeking out what they think are exceptions. Once they've progressed they'll actually be able to spot the difference, and why in some situations something just isn't going to work otherwise. Even then a good programmer will ask some outside opinions from people who are familiar with those cases, before deciding there's no other way. I'd make a drop proc, then make the verb use that proc. Then you coud use it for loads of things- saving time and effort, and space. It's better programming practise. The point is that if it's going to be used by NPCs, or called in any non-verb situation like a disarming attack, you can't simply call the verb as a proc or you've crossed a dangerous boundary--you'll have turned the verb into, effectively, a proc, and all assumptions about usr that were previously kosher have become void. This sort of verb-proc interface is a good way to go in those kinds of situations. Lummox JR | |
Justin Knight wrote:
From what I got out of your post, Leftley, is that robust code is not necessarily better for the person, but better for the coding entirely? All of the problems I have seen with "usr" usually involve the fact that you will have AI or NPC players in your game. What if there are no AI or NPC mobs in the game? A lot of the arguments for robustness usually involve it being general or interchangeable, being able to work in any situation. Isn't that really preference though, and also depends on the game itself? No, it's not preference. It does to an extent depend on the game, but it is not merely in AI/NPC situations that usr abuse can lead to trouble. Even in simple multiplayer situations this can be an issue. In fact even in single-player games, it's really not safe to treat usr as a catch-all for "the player". When we are talking about no usr in proc we mean when we define something as a proc right? Isn't the usage of procs up to the developer a lot of the time? I personally wouldn't use a proc for something like dropping an item, I would use a verb or a HUD button. Aye, for the player's access to it. But what if dropping an item is something that can be done by other verbs, by other procs, by NPCs, etc., as a consequence of an action? If dropping involved more than item.loc=mob.loc, but also included messages, inventory adjustment, triggering traps, etc., it'd require a proc. However, if dropping an item a rare occurance and is something that the player does not need to easily do, I might use a proc. Shouldn't you mold the coding to work with the game, instead of molding the coding to work interchangably? I don't think anyone would argue that most of your procs need be so generic as to be library-worthy. The real point of it is that good practice breeds good results. Sloppy practice breeds bugs, often subtle ones that are not easily diagnosed. Lummox JR | |
Jp wrote:
2 - Don't just replace usr with src. Use an ARGUEMENT. Mind you that's not always the case; sometimes src is correct. For example, in a LevelUp() proc, all you need is src and no arguments, because only one mob is involved at that point. But in a DeathCheck() call that leads to LevelUp(), src should be the victim and you still need an argument for the killer. Lummox JR | |
Mysame wrote:
I must say, I've made lots of custom procs wich were ALL filled with user. Yes, we're aware of this, which is why you consistently have problems with your code. Not all of the problems are caused by the usr abuse, but you can't meaningfully debug a proc without getting to the obvious problems first. Only 2 gave me runtime errors, wich were indeed caused by the "usr" in the proc. And the others will either cause subtle bugs or have the strong potential to do so. Today, it took me around 45 minutes changing all "usr" to "src" in procs. The effect... Bam. Simply bam. Well no kidding. src is not always the best replacement for usr. Sometimes you need to give your proc more information, like an argument, or use the one you have. For example, a common duh moment is this: turf/Enter() The Enter() proc has an argument telling it what atom is trying to enter. turf/Enter(mob/M) Note that in Enter(), src is the turf itself. Most people who abuse usr here realize that src is not the right thing to use, but forget that Enter() has more information that they're not using. I've heard you guys discussed what's the best to use in procs, and came to the conclusion that "src">"usr", but after this I'm just sticking to my own usr abusive procs now... A guy walks into a store and buys a case of mothballs. A week later he comes back for more and the clerk asks, "What happened to the other case you bought last week?" "Well," the customer replies, "you can't expect me to hit the little buggers on every shot!" Burfing the solution doesn't mean the solution is wrong; you merely screwed it up. Replacing all cases of usr with src is not the solution. Replacing usr in procs with the correct var is the solution. That's not what you did, so your results were, predictably, a disaster. Lummox JR | |
Lummox JR explains it much more thoroughly here:
http://www.byondscape.com/ascape.dmb/LummoxJR.2002-1104/ | |
First off, i'm not going to respond to all the stuff you replied. You answered my questions, I understand now and got some clarification on those things.
Lummox JR wrote: Although there are exceptions to the rule, it's important to note that the reason for repeating the mantra is to keep newbies from making the same stupid mistakes over and over and over. The Big Three (usr in procs, the colon operator, and goto) are not to be touched by newbies, who will simply not encounter situations where they actually need to be used. Yes, of course, I completely understand that. However, haven't you seen your "Big Three" misused, as people make sort of a crusade to never have those things in their coding? [link] is one reason why I posted in this thread. DeathAwaitsU posted in my code problems thread while stating "I haven't bothered to try and understand your problem..." Which tells me that he draws these 'usr abuse' and "Big Three" problems based on no real analysis other than 'no usr in proc'(which it was actually attached to mob/DblClick()), and the fact that he was told not to use them. Once they've progressed they'll actually be able to spot the difference, and why in some situations something just isn't going to work otherwise. Isn't that sort of an assumption though? How would they know about it if they were not exposed to the exceptions? If they did not know about exceptions, doesn't that continue their crusade against "The Big Three"? | |
"no put usr in proc, ungh" is much like usr. the phrase does what people want it to do, but they end up using it in places that they shouldn't. they latch onto the saying without knowing why they say it. skysaw's idea of "you probably meant src" wouldn't cause as many problems, but its probably not as much fun to say.
| |
Justin Knight wrote:
Lummox JR wrote: You know, I don't think you were even paying attention in that thread. In the post you described, Click() isn't apparently involved. Is Harm() a verb or a proc? It's not clear in the initial post. DAU made an assumption that it was a proc, but he said nothing about DblClick() there. When Artekia asked if your whole code (meaning the section you posted) wasn't pretty much a proc, he had a point; all you posted at that point was pistol/Harm(), a single unit of code. It's either a verb or it's a proc. In [link] you said Harm() was a proc. Hence, you put usr in a proc, which was not DblClick(). In fact what's quite clear is that you missed the point entirely from [link], where Jp told you that the usr abuse was in a proc called by DblClick(), and that this is an entirely different matter than usr in DblClick() which is fine. Your response: Jp wrote: No, it's used in a proc CALLED by DblClick(). There is a major difference: That's more of a grammar thing than an actual coding problem. Grammar? No, that's pure logic. Two completely different situations, and you just conflated them. usr in DblClick(), usr in proc called by DblClick(). Not the same thing. usr abuse in a proc called by DblClick() is no different than usr abuse in a proc called by a verb. (If you really want to split technicalities, though, it's worse.) To argue that it doesn't matter in this case is to argue that usr abuse doesn't matter in any case, which is ridiculous. EDIT: I read into the post a little more and saw that JamesBurrow IN ADDITION told me to use src in place of usr, when I knew that src was the item, not the person. Another important rule of thumb: Consider the source. Jamesburrow isn't exactly in a position to advise anybody yet. When I actually posted what happened to be part of the problem, Artekia dismissed it as nothing. This makes me very frustrated because of the fact that they weren't helping me at all. I thought Crispy posted saying that usr in DblClick() is valid, but I just realized that for the entire 80 posts no one said that usr was valid in DblClick(), everyone claimed it was a proc. Plenty of people talked about usr being valid in DblClick(), including notably Ol' Yeller in [link]. You responded that that's what you were doing, and Jp quite rightly corrected you that no, you were putting usr in an entirely different proc that was merely being called by DblClick(). What people were on about in that thread is that usr in a proc that is not a virtual verb is not kosher. X in Y, and X in Z called by Y, are not equivalent. Apparently in spite of a multitude of people explaining that, you didn't get it. Note: The : operator was also not my problem there, either. I think that the : operator is given much less credit than it actually deserves. This is not what the topic is about, though. We've been over the : thing before, and really the fact that you couldn't even grok this usr issue just shows you have too little experience to know what you're saying. The : operator is incredibly avoidable in almost all situations (the true exceptions are about as rare as goto exceptions), and worth avoiding because doing so translates potential runtime errors to compile-time errors that are easier to handle. It also forces you to check your types more carefully. Once they've progressed they'll actually be able to spot the difference, and why in some situations something just isn't going to work otherwise. Logically the fact that these things exist dictates that there's got to be some use for them. It just turns out those uses are complex and rare. For a newbie trying to rig up Enter() to spring traps or something, the idea that a segment of code there could be "complex and rare" should raise a huge red flag if they understand that these situations should simply not come up in novice code. It then leads to the question: Is there an easier/safer way to do this than what I'm doing? Intuitive tests like this are a staple of good programming (and for that matter, good debugging). If you get a feeling that something you're doing is possibly wrong, odds are it is. So the admonition to avoid the big three is a very nice toolkit for newbies, including yourself if you're ever willing to use it and thus advance your skill. If they run into a situation where they think they have to use one of these, it becomes a good place to stop and take stock of what they're doing. An intermediate programmer will have been over those moments a lot, and will know once they've reached them whether alternatives are possible, because they'll have explored all kinds of less complex situations. Consider goto: If you're intimately familiar with how to get the most out of while(), do-while(), and for(), with of course a healthy helping of break and continue, and nothing seems to be able to set up the loop you need, odds are that then goto will finally be a good idea. Oh, I have another question. Would making coding robust for NPCs and AI be unnecessary work if that person's game doesn't have or intend to have those? Code is either robust or it isn't; if it's robust then you can implement NPCs and AIs at any time to use it, or at worst you might have to procify a few verbs. The point of writing robust code isn't to make it NPC-proof; it's to make it you-proof. Robust code is like the way fireworks manufacturers separate all their buildings by a certain distance and make sure there's antistatic protection everywhere. In sloppy code, the odds of one bug setting off others are much much better. It doesn't necessarily have to be an obvious bug like a runtime error; it can be something more subtle and evasive. Lummox JR | |
Lummox JR wrote:
You know, I don't think you were even paying attention in that thread. In the post you described, Click() isn't apparently involved. Is Harm() a verb or a proc? It's not clear in the initial post. DAU made an assumption that it was a proc, but he said nothing about DblClick() there. Ah, but you are making an assumption there that I wasn't paying attention. Quite the contrary, I WAS paying attention but you're making this a black and white thing. You're not taking my DM skill at that time into consideration or even how many times I posted in that forum from that time, and this really needs more of a broader approach to that question. Sure, any newb can tap keys and make up some code in DM, but it's different to explain it to people and know the right terminology if you just started coding. Sure, I wasn't typing like a newb but it doesn't dismiss the fact that I was a newb in DM. In addition, that was the second time I was actually posting in the developer forum. The only other time was when I got 150+ errors for not closing a parathesis, which really confused me. People were helpful and nice there, but the first response to my second code problem states "I haven't bothered to try and understand your problem." Wouldn't that make you anrgy or frustrated, considering you were trying to get help for a problem, and someone posts some critiques straight out telling you that they didn't bother to understand it and just skimmed your code? Then Artekia pops in, seemingly to start a fight, defending the guy who didn't bother to understand my problem. Then the topic just starts getting bombarded with posts, which puts me in a bad position, the newbie coder, because everyone is asking me questions or debating something. In [link] you said Harm() was a proc. Hence, you put usr in a proc, which was not DblClick(). This is why I don't like posting on forums, because people tend to take something as small as me happening to call it a proc(Like I said before, I didn't know the correct terminology), and use it against me when I was really trying to tell him that src wouldn't be right there because src is the obj. What I really meant by an obj proc is that an obj is the parent, so saying src would mean the obj itself. Grammar? No, that's pure logic. Two completely different situations, and you just conflated them. usr in DblClick(), usr in proc called by DblClick(). Not the same thing. Again, i'm being bombarded by questions, I didn't know the correct terminology, and you are only taking a small section of what he really typed. I didn't really know what he meant by that and only saw one word being corrected, it looked like he was just correcting my grammar. I read that in context. One thing that I really did know was SRC IS DEFINITELY THE PISTOL. This is what I really had to affirm, and I also had to mention that there are no NPCs or AI in the game, and I don't plan in putting them in, so it really doesn't matter. usr abuse in a proc called by DblClick() is no different than usr abuse in a proc called by a verb. (If you really want to split technicalities, though, it's worse.) To argue that it doesn't matter in this case is to argue that usr abuse doesn't matter in any case, which is ridiculous. Last night, I studied that system in the code thoroughly because I knew you might ask me about this. I have to mention my little story again though. I made icons for the 10 different jobs in Officer Falcon's Deadly Waters, because there was nothing to distinguish the different jobs. He told me he doesn't have the source code anymore and doesn't want to work on it, but Phoenix Man has the source code. Yada yada yada, Phoenix Man wants to update the game and have me do the icons. That didn't work out, he sent the original source code to someone I met in game that said they were a good coder. He had the source code for a month, rarely worked on it, and never told me that he didn't want to work on the game. I got the source code and had to update the game myself. Note that from the beginning all I wanted to put in was a few icons into the game. So I received the original source, mainly Officer Falcon's work, and was working on editing it. So I didn't make all these systems myself, I was just trying to edit one of the items at this time. From all I saw, Harm is simply defined: obj/items I knew for a fact that these things are called when you double click a mob, but I didn't know what interaction they really had. I might have saw it, but I didn't understand what it did. mob/DblClick() Another important rule of thumb: Consider the source. Jamesburrow isn't exactly in a position to advise anybody yet. Like I had mentioned earlier, I was in no position to consider the source because it was only my second topic in this forum. The : operator is incredibly avoidable in almost all situations (the true exceptions are about as rare as goto exceptions), and worth avoiding because doing so translates potential runtime errors to compile-time errors that are easier to handle. It also forces you to check your types more carefully. I don't know really, i've seen it as pretty useful. If I replaced every instance of the : operator with the . operator, I would have to completely redo entire systems in the game. A lot of systems merely work on the fact that the : operator will work there. It's not really that i'm challenging you, it's saying that I do not want to code entire systems from scratch, because it will most likely take me months just to get to the point in which this source code has developed to already. Consider goto: If you're intimately familiar with how to get the most out of while(), do-while(), and for(), with of course a healthy helping of break and continue, and nothing seems to be able to set up the loop you need, odds are that then goto will finally be a good idea. Yes, but will it really come to you in a revelation like that? I don't think that someone will even consider that they HAVE to use one of them, because they've been avoiding it for the entire time they've been coding. In sloppy code, the odds of one bug setting off others are much much better. It doesn't necessarily have to be an obvious bug like a runtime error; it can be something more subtle and evasive. Yes, but isn't this why people run a quick test of what they just did to make sure it has the behavior that they intended it to have? Or does robust coding reduce the amount of testing and checking you need to do? Hm.. I did edit out this question and you did reply after I edited it, so I don't know what happened. | |
I use src in verbs, too. (Well, not in all, sometimes you have to use it, or typecast, or use an argument :-D)
| |
Justin Knight wrote:
Ah, but you are making an assumption there that I wasn't paying attention. Quite the contrary, I WAS paying attention but you're making this a black and white thing. You're not taking my DM skill at that time into consideration or even how many times I posted in that forum from that time, and this really needs more of a broader approach to that question. Actually what I was referring to was that what you were saying in this thread regarding those other posts was a total misread of their actual content. It's not that you didn't know what you were doing at the time, which you didn't, but that your recent interpretation of that thread was wrong. What you said about DeathAwaitsU's and Artekia's posts suggested they were saying something they weren't. Grammar? No, that's pure logic. Two completely different situations, and you just conflated them. usr in DblClick(), usr in proc called by DblClick(). Not the same thing. Poppycock. NPCs and AI are not the only reasons to avoid usr abuse, a point which has already been given copious attention. usr abuse in a proc called by DblClick() is no different than usr abuse in a proc called by a verb. (If you really want to split technicalities, though, it's worse.) To argue that it doesn't matter in this case is to argue that usr abuse doesn't matter in any case, which is ridiculous. Best to fix the obvious problems, then, and you'll have a much more stable game for it. The : operator is incredibly avoidable in almost all situations (the true exceptions are about as rare as goto exceptions), and worth avoiding because doing so translates potential runtime errors to compile-time errors that are easier to handle. It also forces you to check your types more carefully. There are three important words in what you said, and you need to take them to heart: "I don't know". Indeed, you don't know, yet. You haven't had the experience to know, which is why this foolishness about how certain bad methods could be acceptable will get you nowhere. The : operator is not "useful" to you, whether you see it that way or not; it's merely a crutch. I guarantee there's nothing in your code that demands it, or even that is not simply better served by proper type checks. Nobody's saying you need to redo a lot of systems from scratch; rather, you just need to apply the proper type definitions and type-casting. It's not even something you have to do all at once, but a conversion from sloppy code to good code that you can do gradually. Consider goto: If you're intimately familiar with how to get the most out of while(), do-while(), and for(), with of course a healthy helping of break and continue, and nothing seems to be able to set up the loop you need, odds are that then goto will finally be a good idea. If they've become very familiar with how to get the most out of every type of loop, and absolutely nothing works, then it's clear they've stumbled into a loop so complex it requires goto. The reason the rule of thumb is there for newbies and most of the time for intermediates is to remind them to exhaust the alternatives first; a newbie doesn't know all those alternatives, and so will be forced to learn more about loop structures. An intermediate will have run into enough complex loops by this point to know exactly why no alternatives will work. In sloppy code, the odds of one bug setting off others are much much better. It doesn't necessarily have to be an obvious bug like a runtime error; it can be something more subtle and evasive. A quick test won't show the kinds of subtle bugs that brittle programming will expose, in much the same way that a bad weld or cold solder joint in a car might pass a very brief inspection process. Robust code vastly reduces the occurrance of such bugs by 1) lessening the likelihood of any one piece to break down, and 2) isolating separate components so that a problem is unlikely to "jump the gap" and cause worse trouble. It is structured so that if the code must fail, it will fail gracefully. When bugs do occur, they tend not to be showstoppers. Robust code doesn't reduce the amount of checking you need to do. Rather, it sharply reduces the possibility of bugs slipping by your testing. To think you can catch all bugs with simple testing is naïve at best, and to think you can catch subtle ones with little more difficulty is downright blind. You haven't really seen many of those situations yet, but you will. Lummox JR | |
read the bwicki articles.
the problem with usr is that you know what it will usually be, or what it will be in certain cases, but there may be cases where its something that you did not anticipate. so, when someone says "my code doesn't work, what's the problem?", switching usr to src in a proc isn't necessarily the only answer. using usr there will cause problems in some cases, but if this case is one of those anticipated situations, then using usr would coincidentally be correct. while you'd be correct in telling them to switch usr to src, that's not the complete fix. so if you see usr in a proc, take a look for other problems before you just say "no put usr in proc, ungh" and close the case.