17 Mar, 2013, arholly wrote in the 1st comment:
Votes: 0
Hello:
This is related to my other thread. I noticed when doing the static code analyzer, it said some of my variables could be reduced. So, I looked it up and found out it meant to refactor the code. So, I did some basic research on it and found out what it does. Besides being a "good practice", does it pay to do it in a MUD? I'll probably go ahead and do it anyway, since that will reduce the messages I get from the analyzer, but am just curious as to the opinions of my more knowledgeable forum-mates.

Arholly
17 Mar, 2013, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
A code is good when you dont have anything left to remove from it. (povided it is still readable, refactoring does not mean to use complex and smart trick just to reduce the lines of code)
The less code to maintain the better is its, whatever you code.
And useless code is that: useless. Comment it if you want to keep it for some reason (like some variable for debugging purpose only; or better yet #ifdef them)

If you have no time constraints, I suggest you strip your code of everything useless before adding anything.
As a bonus, it makes you read most of it in the process. Helps to have a bigger picture of the code and what will be modified by a seemingly harmless modification.
18 Mar, 2013, Vigud wrote in the 3rd comment:
Votes: 0
You concentrate on silencing warnings instead of understanding what they talk about. It's OK to ignore a warning if you understand it well and decide that the thing it talks about is not worth fixing. Besides, analyzers tend to produce false positives, and you don't want to be fixing fine code because a tool told you that it's bad…
18 Mar, 2013, salindor wrote in the 4th comment:
Votes: 0
I have refactored my mud like three times, and I have to say it has left a sour taste in my mouth.

From a project management point of view, I find it extremely difficult to recommend a refactoring. Each time I have done the refactoring I am not just if the time I spent doing it has yielded the results I was expecting prior to the refactoring.

That aside, the first time I did the refactoring I learned a lot. The people who coded ROM were incredibly smart and I learned a lot of tricks from them I may not have learned otherwise. So from a personal growth perspective, it was extremely enlightening. It also helped me learn how to judge jobs, and decide refactor vs rewrite vs drop the idea far better. I am still not perfect in that area but we learn more from our failures than we do from our successes.

Salindor
18 Mar, 2013, Rarva.Riendf wrote in the 5th comment:
Votes: 0
>The people who coded ROM were incredibly smart

Yeah right..they were good at using tricks to save memory, but from a code design point of view, it was full of shortsighted decision.
18 Mar, 2013, quixadhal wrote in the 6th comment:
Votes: 0
There's also a difference in WHY you're considering refactoring your code.

I would say, if you want to refactor things to make it easier to work on, or change, specific items… go for it. Most Dikurivative codebases are a mess of intertwined systems that makes it very hard to change single systems without touching LOTS of other bits and pieces.

OTOH, if it's just to be more efficient. Go look at your resource usage (top, w, free, whatever tools you like). Are you really using enough CPU or RAM to warrant it? Your time might be better spent fixing bugs or adding features.
18 Mar, 2013, arholly wrote in the 7th comment:
Votes: 0
Vigud said:
You concentrate on silencing warnings instead of understanding what they talk about. It's OK to ignore a warning if you understand it well and decide that the thing it talks about is not worth fixing. Besides, analyzers tend to produce false positives, and you don't want to be fixing fine code because a tool told you that it's bad…

That I have read too, which is why I was curious.
18 Mar, 2013, salindor wrote in the 8th comment:
Votes: 0
Rarva.Riendf said:
>The people who coded ROM were incredibly smart

Yeah right..they were good at using tricks to save memory, but from a code design point of view, it was full of shortsighted decision.


I really can't argue with that. The number one bug I found in each of my refactoring were bugs caused because the maintainers didn't know of a function already to do the new feature and so duplicated the code. Then later on one part of the feature changed and so now you have code doing not the old way and code doing it the new way. Extremely frustrating.
18 Mar, 2013, Rarva.Riendf wrote in the 9th comment:
Votes: 0
salindor said:
I really can't argue with that. The number one bug I found in each of my refactoring were bugs caused because the maintainers didn't know of a function already to do the new feature and so duplicated the code. Then later on one part of the feature changed and so now you have code doing not the old way and code doing it the new way. Extremely frustrating.


No I am talking about design decision:
Having a memory management that prevent any cascade effect. (because everything killing a player outside your loop will effectively break it)
Having mobiles go through a totally different fight/casting/save system.
And I could carry on for more.
(and it is the same for objects)

It was like the multiplayer aspect was a byproduct.
0.0/9