[crossfire] Code cleanlieness and server stability

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
> 
>>  Actually, the server has been relatively stable (in terms of crashes) 
>> recently, IMO.
>>  
>>
> Well, lately it has been reletively crash free compared to some other 
> times in the past, though compared to many other applications and such, 
> crossfire does seem to be a bit flakier both bug and crash wise.

  Perhaps, but this is sometimes hard to measure (and depends what we compare it 
against).

  However, IMO, there is no such thing as having the server too stable.  I doubt 
anyone would complain if it could run for years at a time.


>>  One easy thing I would suggest is that all code developers be on the 
>> crossfire-CVS mailing list so they see the commits, and thus can keep an eye out 
>> for what things have been changed/fixed, and whether that was their code.
>>  
>>
> Agreed, the thing I was proposing above for that was certainly 
> over-engineered and what you're saying alone should be sufficent (and 
> already in practice for most people to my knowledge)

  Right - but there may be a few not on it.

> 
>>  One thing I'd add to such a code cleanup is that there should be the 
>> willingness to break things (that can be fixed on the map level) for cleaner code.
>>
>>  A lot of functions are overly complicated because code was put in place to fix 
>> map bug X, Y, and Z.
>>  
>>
> I'm curious, I haven't heard of any of these cases. Could you give an 
> example?

  Recently, some of the movement stuff might be in this case - I don't know 
specifically if I did any this, but that would be such a situation - some object 
may not work or something, and rather than update 500 maps or 200 archetypes, 
easier to put in a few lines of codes so things work.

  I also don't have any examples, but I know more than once I've been making 
modifications and run across some line of code and look at it for a few minutes 
and thing 'what the heck does this line of code do', or, in many cases, it could 
be clear what it does, and the question is then 'why the heck doe we need to 
have this line of code here'.

  I'd think as part of code cleanup, we'd run across those, and rather than try 
to figure out why we have that line of code there, should just remove it and see 
what breaks.  Especially, if given by the line of code, the behavior could be 
controlled via object/archetype changes.