I just read through the document you linked to, and agree that goto can break logic in unwanted ways. However, the document doesn't address my opinion on the subject. The author is advocating that goto be removed from the standards of most higher level programming languages, and giving reasons to support his position. In doing so, he acknowledges the standard as the final say on a language. Though the use of 'goto' can often be described as 'unwise,' until it is removed from the reference I cannot consider it as being wrong or bad.
| |
Plagu3r wrote:
Could you do me a favor and define "crappy advice". Last I checked, any advice is good. << Gads no. If what you recommend is so totally wrong that it can only make matters worse, it is by definition bad advice. In this case, you had no idea what you were saying. Almost all the instances where usr is used are valid, since they're mostly in Click(). Where usr isn't valid, src is NOT always the correct replacement. So telling VP to change all instances of usr to src is wrong, wrong, wrong. Lummox JR | |
IainPeregrine wrote:
Because DM has such a shallow learning curve, and much of the developer community are persons actively trying to learn the language, many lesser understood aspects of the language are seen as 'dangerous' and are labeled as 'bad.' Examples include the famous 'usr is evil,' 'goto is wrong,' and 'brackets and semicolons are bad.' Actually that's braces, not brackets. Brackets good. Braces I have little problem with if they're being used for a decent reason, such as to shorten a bit of code that probably doesn't need to be 2 or 3 lines. For instance: if(!found) {--i; continue} Where I object to braces, and most BYONDers agree, is where they're totally extraneous, and not only do nothing to help define the code but actively detract from readability by spacing everything out too far. I generally hate reading C code done in the same overspaced style. And "usr is evil" is a bit of a misstatement. More correct is my own catch phrase: "No put usr in proc. Ungh." Though these maxims are generally okay to follow if they help the individual programmer, programmers who are used to other languages are often offended when what is perfectly fine in other languages (and often perfectly fine in DM) is emphatically denounced as 'wrong' or 'bad.' I don't so much denounce most of the above as suggest newbies avoid them like the Plauge. Most newbies do not know how to properly apply usr in a proc, when not to, and how to avoid it; as a result they misuse usr as a crutch and it produces crappy code. The : operator is much the same in that respect: People don't get how to use it properly and how to avoid it. Similarly goto can also be used as a crutch when someone doesn't grasph how to use while() or other basic loops. So I always recommend to newbies that they never use any of the "big three":
| |
Lummox JR wrote:
Actually that's braces, not brackets. Brackets good. This issue has come up before, and it sent me on a search to find out why exactly I say 'brackets' instead of 'braces.' Apparently, 'brackets' is a term used by some Brittish persons to describe a set of parenthesis. Seeing as how I first learned programming from an Englishman, I can see how I picked up this term. I generally accept them as being equivalent. Where I object to braces, and most BYONDers agree, is where they're totally extraneous, and not only do nothing to help define the code but actively detract from readability by spacing everything out too far. I generally hate reading C code done in the same overspaced style. They may be extraneous to you, but a person who actively writes codes in multiple languages may find them helpful. I recently wrote up a long post about why I use brackets, so I don't think you need me to reiterate it here; I can dig up the link if you'd like me to, though. I agree that most Byond users should not use brackets in their code, such a position would be in falacy. However, to denouce the use of brackets by programmers who find them helpful (assuming they can provide good reason) is equally in error. What I object to is the attachment of moral value to pratices which are neither in violation of the standard, nor return errors. Several maxims adopted by this community fosters an elitist mentality which stunts the community's positive growth and perpetuates a 'vigilante' spirit amoung persons with genuinly incorrect practices (and rippers, might I add). And "usr is evil" is a bit of a misstatement. More correct is my own catch phrase: "No put usr in proc. Ungh." Amoung advice to give a person in error, this (if given alone, with no other advice or information) is the worst offense (in my opinion). Not only does this contain no attempt to inform the learning programmer of the proper place of usr or why usr is almost always shouldn't be placed in procs, but it does so using condescending language. In addition to these reasons is the way it is often used. I've seen (and written) many examples of code posted in the help forums which receive just the above as an answer, when the above had nothing to do with why the code didn't work. It's an excuse for trolls to insult new users. I don't so much denounce most of the above as suggest newbies avoid them like the Plauge. Most newbies do not know how to properly apply usr in a proc, when not to, and how to avoid it; as a result they misuse usr as a crutch and it produces crappy code. The : operator is much the same in that respect: People don't get how to use it properly and how to avoid it. Similarly goto can also be used as a crutch when someone doesn't grasph how to use while() or other basic loops. So I always recommend to newbies that they never use any of the "big three":
Yeah, I agree with all of that :) Only twice in DM programming, BTW, have I encountered goto-worthy loops. I used one in a recent project which, unfortunately, looks like it may be too computationally expensive to do in DM; the algorithm came from C, and used a goto there as well. I'd be interested in seeing either, because I've never found a good use for goto. I certainly have never subscribed to the opinion that goto is a dinosaur to be avoided at all costs. However I do always recommend that newbies avoid it at all costs, just because there's simply nothing that complex they would be doing, but the temptation to use it where it doesn't belong is often much too strong. Again, I agree. Our positions are not mutually exclusive. Basically, what I advocate is that a person trying to give advice should seek to understand why a person is using a particular technique, and shouldn't judge practices based upon his own preferences. Rather, techniques should be judged according to the standard, and wether or not they compile/run without errors (or the potential for error). Beyond that, advice for how to avoid problems, or suggestions on what might be preferable considering community standards, is fine. What I really can't stand is seeing posts that read "Braces are wrong. Get rid of all of them now." when all the user needed was to be told that he spelled 'players_connected_ot_world[]' wrong. [Edit: Normally, I read this for spelling or grammer errors... but I'm late for class. Apollogies ni andvace.] | |
Lummox wrote:
And "usr is evil" is a bit of a misstatement. More correct is >my own catch phrase: "No put usr in proc. Ungh." IainPeregrine wrote: I've seen (and written) many examples of code posted in the help forums which receive just the above as an answer, when the above had nothing to do with why the code didn't work. It's an excuse for trolls to insult new users. Regardless of whether or not it's relevant to the problem at hand, it is a problem that still needs to be addressed. I don't see how pointing out that it is a problem is something that should be quickly dismissed because it won't fix the other problem! How can you even consider it to be detrimental when someone points out that you have additional flaws in your code? Though, it's most likely in the delivery of said advice. Perhaps Lummox should make his catchphrase link to his must-read "usr Unfriendly" article. :) | |
I really enjoy when coders get together and argue about advice and techniques, when they really aren't helping the person.
You guys are seriously off topic, oh yeah you can say "It's related because he's going to read all these documents and get help from them." No, you guys aren't even adressing him, you're bickering amongst yourselves about different code techniques. Don't post in "Code Problems" unless you're posting about the "Code Problem" the person has posted about. A topic this long could quite possibly be overlooked by many people, considering it's that long. Long topics usually mean they are solved, not filled with unrelated discussions to the topic. Yes, yes Plagu3r's advice was incorrect, but don't spam the topic arguements/discussions on it. Especially if that discussion/arguement is unrelated to the code problem. "Here's some advice" "That advice is wrong" "How is it wrong?" "It's wrong because of this." "Yes, that is definitely wrong." "This is definitely wrong too." "Yes that is also wrong." "Actually, it's not that wrong." "Here's a long explaination on how that is wrong." "Uh guys.. can I get some right advice for a change?" | |
Actually, it is good. It helps stop people from posting the wrong infomation, and giving the author the incorrect answer. When he would try changing usr in the click proc, it will give him undefined errors. Then he will come here when it doesn't work. You have to nip these things in the bud. Get rid of them before it causes a problem.
| |
If that advice is wrong, people say that it is. There is no need for many, many posts about that persons wrong advice, which is completely unrelated to the code problem. It's mainly people saying "shame on you for bad advice" and the code problem poster does not need to read that.
| |
I agree, but partly.. :/.
Correcting a mistake is right, nothing wrong with it. But some people are just to stubborn to realise that they made an mistake and then start a discussion. In my opinion the "corrector" shouldn't be replying to the "discussion starter" at all. That's one of the ways it goes. They other way is: When someone corrects someone, the one that corrects isn't really telling him what he had done wrong, he just corrects the code. Then the one who got corrected gets a little mad, and then the whole discussion, and sometimes even a flame war. Also a very stupid way of helping someone out with a code. I think there should be something done about this, it's a shame to see all those threads being spammed.. O-matic | |
You have indentation wrong in soooo many ways. (sort of)
I'm surprised NOONE cought this part. switch(input("Which race would you like to be.","Character Creation") input always set to usr. SO you (I think) have usr abuse here. so I believe you might want to set this to: ...input(new_mob,"Which race... Could be wrong Also, look at yout indentation after the Switch statement. No wonder it will not work one bit. mob What is this? It looks like your trying to make an obj? inside the Logout() proc. I would suggest putting your Character Creation System inside procs instead, so you don't have to use 'goto' and just call the proc. I am suggesting you DON'T mix usr with src, like you did with the Logout() proc very very messy and wrong. new_mob.name = char_name This also will not work AT ALL. del(src) will be referring to the obj that this has been placed into. I also beleive the indentation is ALL WRONG here to. You should REALLY REALLY make it into procs. | |
Also, there's one more problem. In Logout(), src may not always be the person who is logging out. It could result in undefined behavior if someone else calls another user's logout proc. Also, why del( src ) yourself when you can just call the parent proc and have it do it? You should be getting a compiler error with your else without a matching if in Logout(), as well.
| |
Go To Statement Considered Harmful