良好习惯的建议. [英] Advice on good practise.

问题描述

我有两种解决问题的方法，虽然我可以找到所需的工作，但我想知道在Case语句中包含一组嵌套的If-Then是否是一种好习惯.

我所拥有的有效，但是看起来很丑.

I have a couple of approaches to a problem, and whilst I can get what I need to work I want to know if it is good practice to have a set of nested If-Then''s inside a Case statement.

What I have works, but looks ugly.

推荐答案

Dalek，您是成熟的开发人员，可能需要一个认真的答案.
我很感谢您正在尝试改进基本知识.

使用嵌套结构高度依赖于语言.由于一些因素，我过去常常避免与Pascal嵌套，而让自己在C#中多出1-2个级别. C#的可读性不是其中之一(实际上更差)；可以在体内任何地方声明局部变量.

通常，我通过将嵌套部分抽象为单独的方法来避免像您描述的那样嵌套.很有可能，它们也可以被重用.您可能会说您不能将if块作为函数抽象出来，因为如果不是谓词，但可能在if块下包含不同的语句主体.在这种情况下:1)您始终可以将委托用作此类函数的参数； 2)是否可以让您有机会重新查看块的代码并概括/参数化分支下的操作.换句话说，减少嵌套的尝试可能会促使您更好地重用和抽象.

但是在这里我想提一个有趣的部分.您是否想知道如何完全消除if块中的switch块?

如果if分支的switch案例过多，则Tho非常有用.如果案例数超过4个左右并且分支太长，我会更多地考虑使用交换机，并考虑使用此技术.
该技术基于字典.案例选择器变成了字典的键，而字典的值是一个委托，用于响应键而调用某些操作".选择动作和调用委托实例(动作调用")是在单个调用中完成的，例如result = Dispatcher.Invoke(key).有人演示了这种技术，但是我的更好.它是完全通用的，并且具有多播变体(代表队列，调用返回结果数组).有趣的部分是可以将服务器作为另一个OOP"的模型.实际上，在对象Pascal中，OOP的机制过于并行:一种基于传统VMT，另一种基于DMT(动态方法表").在内部，DMT应该是我所描述的.同样，有时需要稍微滥用OOP-密钥可能是类型.我知道至少有一个用例可以证明这种滥用是合理的.

当您遇到很多情况时，它也可以从根本上提高性能.

也许，我应该发表它.如果您有兴趣，我会告诉您.这是C#，但是对于.NET，没有必要的语言界限.

Dalek, you''re a mature developer, may need a serious answer.
I appreciate you''re trying to refine technique for the elementary stuff.

Working with nested structures highly depend on the language. I used to avoid nesting with Pascal and allow myself 1-2 levels more with C#, due to several factors. Readability of C# is not one of them (it''s actually worse); it''s more of the ability to declare local variable anywhere in the body.

Generally, I try to avoid nesting like you describe by abstracting out nested parts to separate methods. Chances are, they will also can be reused. You may say that you cannot abstract out an if block as a function, because if may not be a predicate, but may have a body of different statements under the if block. In this case 1) you can always use a delegate as a parameter of such function; 2) if may give you a chance to re-view the code of the block and generalize/parametrize the actions under the branches. In other word, a mere attempt to reduce nesting might push you into better reuse and abstraction.

But here I wanted to mention a fun part. Do you want to know how you can eliminate switch block of an if block completely?

Tho is very useful if there too many switch cases of if branches. I more fight against switches and think about using this technique if the number of cases goes beyond 4 or so, and the branches are too long.
The technique is based on a dictionary. What was a case selector becomes a key of a dictionary, and a value of a dictionary is a delegate, used to "invoke some action in response to a key". Selection of action and a call to delegate instance ("action invocation") is done in a single call like result = Dispatcher.Invoke(key). Somebody demonstrated this technique, but mine is better. It is completely generic and has a multi-cast variant (a queue of delegates, invocation returns array of results). The funny part is that can server as a model of "another OOP". In fact, it was too parallel mechanisms of OOP in Object Pascal: one based in traditional VMT, another - on DMT ("Dynamic method table"). Internally, DMT should be what I describe. Also, sometime need to abuse OOP a bit -- keys could be types. I know at least one use case when such abuse if perfectly justified.

When you have many cases, it also essentially improves performance.

Maybe, I should publish it. If you''re interested, I''ll show you. This is C#, but with .NET there no essential language boundaries.

您可能有嵌套的切换用例-实际上可能比嵌套的用例好.

You could have nested switch cases - that might actually be better than nested if''s.

通常，我尽量不要在Case语句中嵌套太多.我为每个选择都创建了一个单独的方法，并在其中进行了研究.在这种情况下，可读性更好.

Generally I try not to have too much nesting inside Case statement. I make a separate method for each choice and work inside it. Readability is better preserved in that case.

这篇关于良好习惯的建议.的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！