Coding guideline for VB.NET

Question

1.50/5 (2 votes)

See more:

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:

VB

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.

Posted 31-Jan-16 13:41pm

InnesSpring

Updated 31-Jan-16 14:23pm

PIEBALDconsult

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 31-Jan-16 20:26pm

How about two code samples for the options related to "code evaluation withing method call"?
—SA

PIEBALDconsult 31-Jan-16 20:32pm

So what if they're not needed; he shouldn't remove them.
If your team has a coding/style standard, then you should follow it, if the standard is not to put in the parentheses (which is very likely) then you should _not_ put them in in the first place; and if you do, then _you_ should remove them, not your teammates.
If you accepted a job writing VB (as I did once), then dummy up and write VB, not C#!
And VB does not lend itself to "writing less code".

InnesSpring 31-Jan-16 20:52pm

Thank you PIEBALDconsult. Our team does not have a coding/style standard and therefore, I asked a question. If they have it I will follow their standards.

F. Xaver 1-Feb-16 3:22am

I don't get your method call thing, maybe get us a example?
but speaking of short code: If a <= 20 Then c+= 1

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2016-01-31T14:06:00

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