It wont damage!

Page: 1 2 3 4 5 6
Nov 22 2005, 1:32 pm
In response to Dever
I don't know about you, but I'd rather have a slower game than a broken and unflexible game. I don't know how much slower it might be to send one more parameter through a proc, but I'm willing to be that it isn't any noticable unless you are calling the proc a couple million times.

~~> Unknown Person
Nov 22 2005, 1:35 pm
In response to Unknown Person
Unknown Person wrote:
I don't know about you, but I'd rather have a slower game than a broken and unflexible game. I don't know how much slower it might be to send one more parameter through a proc, but I'm willing to be that it isn't any noticable unless you are calling the proc a couple million times.

~~> Unknown Person


Maybe unflexible in its current state, but not broken. The fact is though, that if needed. JUST REWRITE IT! And now its fixed for that new situation. That simple.
Nov 22 2005, 1:38 pm
In response to Dever
But why fix it if you just did it correct the first time?!
Nov 22 2005, 1:42 pm
In response to Mega fart cannon
Mega fart cannon wrote:
But why fix it if you just did it correct the first time?!


It is correct for that situation. If the situation changes, then it needs to be fixed. You are not reading my statements correctly.
Nov 22 2005, 1:47 pm
In response to Dever
It's called thinking ahead, you need to brainstorm what the proc will do, have, etc., and also thinking of the ways it can go wrong, so you don't have to go back and change it in the future when you could've just inputted protective measures on it or make it do multiple things.
Nov 22 2005, 1:48 pm
In response to Dever
Dever wrote:
Maybe unflexible in its current state, but not broken. The fact is though, that if needed. JUST REWRITE IT! And now its fixed for that new situation. That simple.

Simple indeed, though you're putting unnecesary work for yourself. I don't understand why you would want to change your function to fit a specific need rather than making your function more flexible, especially if making it more flexible being passing one more argument. I would doubt that passing one more argument would ruin it's efficiency, especially if you are going to use it more than one way.

~~> Unknown Person
Nov 22 2005, 1:57 pm
In response to Mega fart cannon
Mega fart cannon wrote:
It's called thinking ahead, you need to brainstorm what the proc will do, have, etc., and also thinking of the ways it can go wrong, so you don't have to go back and change it in the future when you could've just inputted protective measures on it or make it do multiple things.


No, I don't need that. You still don't understand. It needs to be written for how it is being currently used. If that changes, then it can be rewritten. As long it is written specificly, it can be more effienct. Thats just the way it is. If you want to be lazy and make it 'robust' then go ahead, but I can assure it won't be as effienct.
Nov 22 2005, 1:58 pm
In response to Unknown Person
Unknown Person wrote:
Dever wrote:
Maybe unflexible in its current state, but not broken. The fact is though, that if needed. JUST REWRITE IT! And now its fixed for that new situation. That simple.

Simple indeed, though you're putting unnecesary work for yourself. I don't understand why you would want to change your function to fit a specific need rather than making your function more flexible, especially if making it more flexible being passing one more argument. I would doubt that passing one more argument would ruin it's efficiency, especially if you are going to use it more than one way.

~~> Unknown Person

That 'unecessary' work as you call it is what makes it better. Put the effort to make things work the way they should.
Nov 22 2005, 2:16 pm (Edited on Nov 22 2005, 2:41 pm)
In response to Dever
Dever wrote:
That 'unecessary' work as you call it is what makes it better. Put the effort to make things work the way they should.

You definately have the weirdest habits I have seen when it comes to the subject of programming. Sure, I've been programming for a little under a year, but I'm not anywhere near as persistent as you are. If you have done -any- debugging of apps that you wrote in C++, then you'd know that some of the tiny errors come from stupid things. Things like forgetting to initialize a variable, or forgetting to delete what you new'd or free'ing what you malloc'ed. Or forgetting a call to a function.

When debugging larger applications, you will run into a lot more problems than the above, and it will become a hassle going through ~10,000+ lines of code because you made one small mistake. That's why it's better to take the proper measures in the first place, like mentioned before, using assert() to check your variables. Using try...catch will also help quite a few things, and writing a simple logging class to save engine output.

I've never met ANYONE who wouldn't think about reusability. ( In the above arguments, a flexible function is a function that can be reused. )

I'll edit my post as I think of more to post.

-- Code Example: I'm jealous ( Mega Fart Cannon. Bleh )

#include <iostream>


int main()
{
     int x, y = 5;
     x = x + y - y; // Alright, this is 0, right?
     std::cout << x << std::endl; // Output it and...
                    // Don't complain if it doesn't output 0.
                    // The standard doesn't guarantee
                    // That a variable is initialized to 0
                    // So, it could be ANYTHING.
                    // This is one of those situations where...
                    // You should be safe ahead of time and 
                    // Do this: 
};


Proper Example:
#include <iostream>

int main()
{
     int x , y = 5;
//     assert( !x )     // One method
     if( x )
     {
          x = 0;          // Initialize
               // This is the other method of being safe.
     };

     x = x + y - y;     // This will ALWAYS be 0.
     std::cout << x << std::endl;
               // Now we're happy.
};


That was just one example where it isn't AS bad. It's when you're making real calculations that it gets bad. That's why you need to do the extra work the first time.
Nov 22 2005, 2:16 pm
In response to Dever
 
/*Back to my other post, if you want to make something 
teleport, you can do that. But what if you wanted to add
NPCs and such? Since you don't have the correct
checks and such in that one proc, things can go wrong,
and then you'll have to go a fix them.
Another example would be:*/

mob/proc/Torch_NPC(mob/M)
  M.HP-=10
  src<<"You torch [M]!"
  M.Death(src)

obj/spell
  Click()
    var/mob/M=usr.target
    usr.Torch_NPC(M)

/*So you're thinking in your mind, "Oh, this is perfect, 
nothing can go wrong...", and then, a random player 
target's a NPC (not a monster), and destroy's it. You'd 
have to go back and fix the error. That's thinking ahead for you. Here's another
example about robustness:*/

mob/proc/Death(mob/M)
  if(M.HP==0)  //A newbie mistake, but this is just an example
    world<<"[M] dies!"
    del(M)

mob/monster
  Bump(O)
    if(ismob(O))
      O:HP-=10
      O.Death(src)
    ..()

/*These are newbie examples. (Not to single anyone out or 
anything) Certainly, these two procs have their sole 
purpose down, their reason of living. But, these two procs 
also have a great possibility of crashing. Doing '==0/==1' 
checks are horrible. While doing '!var/var' checks are much
more robust, yet are AS efficient as the other. But 
in this case, you need '<=0'. In the Bump() proc, it uses
':' colon operator. Great tool for efficiency in 
memory usage, but not in common programming. O could be 
type-casted, or turned into 'mob/O', both ways void the 
use of the colon operator.*/
Nov 22 2005, 3:55 pm
In response to Mega fart cannon
 
mob/proc/Torch_NPC(mob/M)
  M.HP-=10
  src<<"You torch [M]!"
  M.Death(src)

obj/spell
  Click()
    var/mob/M=usr.target
    usr.Torch_NPC(M)


You see, that is completely wrong.

obj/spell
  Click()
      usr.target.HP-=10
      usr<<"You torch [usr.target]!"
      if(M.HP<=0)
        world<<"[usr.target] dies!"
        del(usr.target)


This is better.

Nov 22 2005, 4:06 pm
In response to Dever
I know it is, that's why I used it as an example.
Nov 22 2005, 4:07 pm
In response to Mega fart cannon
Mega fart cannon wrote:
I know it is, that's why I used it as an example.

An example that only proved me correct.
Nov 22 2005, 4:11 pm
In response to Dever
Fine fine, that example was a poor one, but the other one gets the point through though.
Nov 22 2005, 4:17 pm
In response to Dever
Dever, say you're working on a big BYOND project. An actual, decent game. Probably, at the least, 5000 lines of code.

And every time you make a little change to something, you're going to have to go and check, and rewrite, half of those lines because you're being a stupid idiot and using usr in places it shouldn't be used. That is not good.
Nov 22 2005, 4:23 pm
In response to Jp
Jp wrote:
Dever, say you're working on a big BYOND project. An actual, decent game. Probably, at the least, 5000 lines of code.

And every time you make a little change to something, you're going to have to go and check, and rewrite, half of those lines because you're being a stupid idiot and using usr in places it shouldn't be used. That is not good.


According to Lummox and others, there is never a place to ue usr. Which is incorrect. There alot of places where using usr is more effienct, and so I will use it there.
Nov 22 2005, 4:45 pm
In response to Dever
Incorrect, thanks for playing!

No, Lummox states that there is no place for usr inside a proc. Inside verbs (Or pseudoverbs, like Click()), usr is quite okay, and Lummox wouldn't begrudge the use of it there.
Nov 22 2005, 4:46 pm
In response to Dever
Dever wrote:
Jp wrote:
Dever, say you're working on a big BYOND project. An actual, decent game. Probably, at the least, 5000 lines of code.

And every time you make a little change to something, you're going to have to go and check, and rewrite, half of those lines because you're being a stupid idiot and using usr in places it shouldn't be used. That is not good.


According to Lummox and others, there is never a place to ue usr. Which is incorrect. There alot of places where using usr is more effienct, and so I will use it there.

I don't believe that Lummox or anyone else ever said that there was never a place to use usr. You're just like Kija was, he tried to twist what Lummox and others said and ended up worse off than he was to begin with.

Lummox DID say that there was no place to use usr IN PROCS.
Nov 22 2005, 4:47 pm
In response to Dever
Dever wrote:
According to Lummox and others, there is never a place to ue usr. Which is incorrect.

Totally wrong. Read the Usr Lecture.
Nov 22 2005, 4:51 pm (Edited on Nov 22 2005, 5:06 pm)
In response to Audeuro
I did no such thing. Please do not bring me into this by lieing about me. I do not wish to see more of these petty insults. It is rather sad to see you people fling these about rather than acting civil and just explain your side of it without relying on them.

I never said that Lummox said usr was bad in all cases, and you will not find a quote that shows that I do. Now, why don't you stop twisting others people's words and lieing about them, and simply stop posting if you have nothing good to say, or actually post something that has to do with the topic?

Not only that, I am still right. And this discussion is very similiar to mine. And yet again, it is the exact same insults, the exact same reliance on these "facts" rather than the topic. Even if it was a fact, does not mean you should say it. Would you go up to a burn victim and say "Hah! You are so ugly! But you cannot be mad at me; I am just stating the facts!" Whether it is true or not, it is still an insult, and still pointless and pathetic to say. Although, in this case these "facts" are not true. They are insults and have no place here.

Ofcourse, my example, you could say that in certain cases, you could say that to someone. I am not argueing that, I am argueing that stating something as a fact does not make less of an insult. People seem to forget that it does not matter who knows more, but who is right. And so instead of pointing out the correct topic and argueing against it, they simply brag about how much smarter and better they are and hope that will prove them correct. Yes, I do realize that some points have been made, but very few compared to these insults still being flung about, even at people not in the current topic.



Page: 1 2 3 4 5 6