views:

178

answers:

2

There are quite a few of IRC server codes

I am working on a small IRC client for Adobe AIR, and I started out by supporting only a few of these initially, and then a switch statement didn't seem like a bad idea. But as I support more and more, the switch statement is getting longer and it feels like it's a little out of control. One issue is that I've kept the low level IRC handling code in a file on its own so that it can be reused. I would like to keep everything in one file. Another issue is that code blocks in the switch statements currently assume to be part of this IRC class and there's frequent use of the this statement. Making changes now would be a lot of work and introduce regressions. The only problem really is my distaste for a long switch statement, otherwise you know it works, and it's kind of easy to read, but not really making it more difficult to maintain. But it's such a long switch statement. And the function that contains the switch statement is obviously long too. ://

One thing I sometimes do in lieu of a switch is that I define functions that are named after the value the switch evaluates. Instead of a switch:

switch ( val ) {
  case: "alert":
    alert( "yo" );
    break;
}

I check to see if a method exists in scope and execute it:

obj.alert = function ( ) {
  alert( "yo" );
}

if ( val in obj && isFunction( obj[ val ] ) ) { 
  obj[ val ]( );
}

But again in this case I've feel like there's a high risk in regressions and I'm not sure it's worth the effort only to avoid having a long switch statement, for the sake of its length.

+1  A: 

why not keep the switch in a parameter file with predefined exit points along with their arguments read the file at the startup and keep in in memory

A.Rashad
So you agree then that changes should be risked for the sole reason of the length of the switch?
apphacker
and the flexibility of maintaining your program. instead of changing the code every time required. an intermediate level user can change the script/configuration file and a restart to take place
A.Rashad
+4  A: 

Why don't you keep a hash (a JavaScript {} object) with the code as the key and the function as the value? Then, for small pieces of code you could use an anonymous function, and for bigger pieces of code you could just have a reference to an already written function. I don't know anything about IRC, but here's a small example:

var CodeHash = {
    001: function() { /* Do something... */ },
    002: BigImportantObject.someFunction
}

Kind of a bad example, but you get the idea.


Edit: If you believe that you can maintain such a long switch statement easily and without problems, then I think it's ridiculous to rewrite your program just to remove the switch. But I know that I, personally, would much rather maintain a hash table like above than a huge switch statement, for many reasons. So it's up to you. Seems like a rhetorical question if you keep insisting that the only reason you'd rewrite your code is to get rid of the switch statement.

musicfreak
Because then you are a declaring a whole lot of functions again and again each time you create an instance of this IRC class for the sole reason that a switch is too long. Note that when you use the prototype object to add functions, you only declare the functions once for all instances.
apphacker
But my question is really, should if I should use a switch. So your answer is no then? I shouldn't? I should risk a rewrite?
apphacker
I think it would be easier to rewrite some parts now than try to maintain a huge switch statement, personally. I don't know about you but I'd hate to maintain that.
musicfreak
It's not really important, I only want to know if I should make modifications now. The only reason I would be is to get rid of a very long switch statement. The length of the switch statement is really the only reason this change would happen. A long object like this doesn't seem like a better (more maintainable/easier to read) solution.
apphacker
@apphacker: your resistance to this method doesn't make any sense. If you provided the code for your IRC "class", then maybe we could understand. and if you want it on the prototype, then just change it to: IRC.prototype.CodeHash = { /* sample above */ }
Jonathan Fingland
@apphacker: A huge switch statement *is* harder to maintain. Imagine if you forget a "break" somewhere in there. How long do you imagine it will take you to find that bug? Also, I imagine you would repeat yourself a lot, although without seeing any actual code it's hard to tell.
musicfreak
The other thing that makes a switch statement hard to maintain is that all the cases share the same scope. If your code inside a case needs parameters, you need to deal with that manually. One thing you can do is not change over from a switch statement all at once. Implement new server codes in the hash as functions. Then before the switch, have an if(code in hash) { hash[code](params)} else {switch(code){...}}... Then you can move your existing codes over to the hash one by one, don't even have to delete stuff from the switch. Once you've moved everything, simply remove the "else" clause
Breton