使用 switch 语句来处理 irc 服务器代码会很荒谬吗?

发布于 2024-07-25 10:03:16 字数 913 浏览 10 评论 0原文

有相当多的一些IRC服务器代码

我正在开发一个小的Adobe AIR 的 IRC 客户端,我一开始只支持其中的几个,然后似乎没有 switch 语句就像一个坏主意。 但随着我支持的越来越多,switch语句也越来越长,感觉有点失控了。 一个问题是我将低级 IRC 处理代码单独保存在一个文件中,以便可以重用。 我想将所有内容保存在一个文件中。 另一个问题是 switch 语句中的代码块当前被假定为该 IRC 类的一部分,并且经常使用 this 语句。 现在进行更改将需要大量工作并引入回归。 唯一的问题确实是我不喜欢很长的 switch 语句,否则你知道它是有效的,而且它很容易阅读,但并没有真正使其更难以维护。 但这是一个很长的 switch 语句。 而且包含 switch 语句的函数显然也很长。 ://

我有时代替开关做的一件事是定义以开关评估的值命名的函数。 而不是切换:

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

我检查范围内是否存在一个方法并执行它:

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

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

但在这种情况下,我再次感觉回归存在很高的风险,并且我不确定是否值得付出努力来避免出现很长的 switch 语句,因为它的长度。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

森林迷了鹿 2024-08-01 10:03:16

为什么不保留一个以代码为键、以函数为值的哈希(JavaScript {} 对象)? 然后,对于小段代码,您可以使用匿名函数,而对于较大的代码段,您可以只引用已编写的函数。 我对 IRC 一无所知,但这里有一个小例子:

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

有点糟糕,但你明白了。


编辑:如果您相信您可以轻松且没有问题地维护这么长的switch语句,那么我认为仅仅为了删除switch而重写您的程序是荒谬的。 但我知道,出于多种原因,我个人更愿意维护一个像上面这样的哈希表,而不是一个巨大的 switch 语句。 所以这取决于你。 如果您坚持认为重写代码的唯一原因是删除 switch 语句,这似乎是一个反问句。

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.

天煞孤星 2024-08-01 10:03:16

为什么不将开关保留在具有预定义退出点及其参数的参数文件中
启动时读取文件并保存在内存中

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文