VB.NET的编码指南 [英] Coding guideline for VB.NET
问题描述
我是VB.net的新手，我来自一个习惯使用C＃的环境。我习惯将条件语句放在括号中，而我现在的同事通过删除它们来重写我的代码。您如何将评估条件放在括号中？请参阅下面的示例：
I am new in VB.net and I am coming from an environment where I used to work with C#. I have a habit putting conditional statements in brackets and my current colleague is rewriting my code by removing them. What do you think about putting evaluating condition in a bracket? See example below:
If (a <= 20) Then
c= c+1
End If
另外，他提到编写更少的代码总是更好。例如，最好在方法调用或首次执行语句评估中传递评估语句，然后将结果存储在变量中，然后将变量作为参数传递给方法调用。如果在方法调用中进行代码评估，它会如何影响性能？
我喜欢写更少的代码，但我认为有些情况下代码不是最好的选择。
Also, he mentioned that is always better to write less code. For example is it better to pass evaluation statement in a method call or first do statement evaluation and then store a result in a variable and then pass a variable as a parameter to a method call. How is it affecting performance if you are doing code evaluation within method call?
I like to write less code but also I think there are some scenarios where less code is not the best option.
推荐答案
这是可能的您的同事是一名不合格的开发人员，使用C / C ++ / C＃/ Java或其他具有类C语法经验的语言。这种纠正是愚蠢的。 Basic根本不需要那些括号。有时多余的标点符号很好甚至可以提高可读性，但通常多余的东西都是邪恶的;在这种特殊情况下，这只不过是愚蠢。
解释：Basic中不需要这些括号，因为保留字然后已经充当了足够的分隔符。在具有C列表语法的语言中，圆括号很重要，因为条件语句在条件之后立即出现。
尽管你的同事是对的更好写更少的代码，但总是是完全错误的。较少的代码通常更具可读性，但在很多情况下，缩短代码会使其难以读取。关于它没有普遍的自然法则。
此外，更短或更长的代码并不直接转化为该代码的时间复杂性和性能。在执行时间内可以使代码更少，反之亦然，更长的代码可以提供更快的编译代码。我甚至不会在这里讨论，因为必要的讨论总是归结为许多不同的情况。如果你真的了解编译的结果，你可以感受到它。
一条经验法则说：不做手动优化。通常，代码通过更好的设计获得性能，而不是小的实现细节。但是根据所有经验法则，这个经验法则在100％的情况下不起作用。
怎么办？同样，重要的是要清楚地了解代码在CPU指令，寄存器，内存，端口和OS调用级别上的含义。你不需要记住整个指令集和操作的所有细节（你不应该在编写代码时想象所有这些操作），但是在你的教育的某些阶段学习它并收集一些基本的经验可能真的很好为您的高级语言代码的质量。是的，我说可以。如果我不面对许多不好的开发人员，每次他们学习新东西都会变得更糟，我会说总是非常好。
对不起，我只是忽略了使用方法调用进行代码评估部分。我不认为你的描述是清楚明确的。如果你写两个代码示例显示两个选择的变体，我很乐意尝试分析它们。
再次，不要记得代码的可维护性非常重要;它很少会牺牲性能而牺牲。通常，在非常好的代码中，一切都更好，可维护性和性能。
-SA
It's possible that your colleague is an unqualified developer with C/C++/C#/Java or other language with C-like syntax experience. This "correction" is stupid. Basic does not need those brackets at all. Sometimes redundant punctuation is fine or even can improve readability, but usually anything redundant is evil; in this particular case, this is nothing but stupidity.
Explanation: those brackets are not needed in Basic, because reserved word "then" already acts as sufficient delimiter. In languages with C-list syntax, round brackets are important, because conditional statement comes immediately after the condition.
Even though your colleague is right about "better to write less code", but "always" is totally wrong. Less code is usually more readable, but there are many cases when shortening code can make it poorly readable. There is no a universal law of nature about it.
Also, shorter or longer code does not directly translate to the time complexity and performance of that code. Less code can be made considerably worse in execution time and visa versa, longer code can be give faster compiled code. I would not even discuss it here, because the essential discussion will always boil down to many different cases. You can get feel of it if you really understand what is the result of compilation.
One rule of thumb says: don't do "manual" optimization. Usually, code gain in performance through better design, not small implementation detail. But as all rules of thumb, this rule of thumb does not work in 100% of cases.
What to do? Again, it's important to get a clear idea on what your code means at the level of CPU instruction, registers, memory, ports and OS calls. You don't need to remember the whole instruction set and all the detail of operation (and you should not picture all this operation as you write code), but learning it at some point of your education and gathering some essential experience can be really good for the quality of you high-level language code. Yes, I said "can be". I would love to say "always really good" if I did not face many developers who are not good and become even worse every time they learn something new.
Sorry, I just ignored "code evaluation withing method call" part. I don't think your description is clear and unambiguous. If you write two code samples showing two variants of choice, I'll gladly try to analyze them.
Again, don't remember that maintainability of code is extremely important; it can very rarely be sacrificed in favor of performance. Usually, in really good code, everything is better, maintainability and performance.
—SA
这篇关于VB.NET的编码指南的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
