Rules of Thumb

[x-ice]

Talking about rules of thumb, i know a few programmers and most of them are so bad at it, maybe a few rules of thumb could help people who have bad programming practise.

• Always comment your code well so you can return to your code anytime and still understand it fully

• Always use descriptive names for controls and variables, also use naming conventions so you can know the type of control or variable.

• You can use regions in your .NET IDE to separate code. E.g. I do it like this. (see Figure 1.0)

  #Region "Public Declaration"
   
  #End Region
   
  #Region "Form Code"
   
  #End Region
   
  #Region "Sub Procedures"
   
  #End Region

  Your regions can then be expanding or contracted so that you can only see the code for regions you have expanded, this helps me focus only on the code i want to.

Anybody got any more rules of thumb?

[ntg]

"Rules of thumb" may be useful but sometimes you can't get people to agree upon what should be considered a rule of thumb. Sometimes s are set by the company you work with (or your boss) and that can change.

Comment every line of code, so you can return to the code later and know exactly what it does. (Only comment lines that need to commented, if its obvious then leave it

That's really confusing since what's obvious to you might not be obvious to me.

When using constructs (IE, IF...THEN...ELSE, DO...LOOP, SELECT CASE, etc...) indent all code inside the construct by 1 tab space, therefore it becomes alot easier to read.

I wouldn't really call this a rule. Most IDEs do that anyway nowadays.

If you are setting multiple properties for the same control use a WITH construct.

With textbox1
    .Enabled = True
    .Locked = True
    .Text = "bla"
End With

I know lots of people who hate WITHs. If your statement block is large, having a .SomeProperty somewhere inside the block can be confusing. Also, you can't copy-paste the .SomeProperty to the Watches window since the IDE will complain that it's inadequately qualified.

I would think that it's better to focus on more fundumental things (like "Always use meaningful names instead of TextBox1" etc).

[RobDog888]

Probably basic ones but, for every class/module...

• 
  Always use Option Explicit On
  
  
• 
  Always use Option Strict On
  
  
• 
  Declare your variables with the narrowest scope needed.
  

  For [color=black]i[/color] As Integer [color=black]= 0[/color] To [color=black]9[/color]
      'Do something
  Next
   
  'Or
   
  Private Sub [color=black]Button1_Click[/color](ByVal [color=black]sender[/color] As [color=black]System.Object, [/color][color=navy]ByVal[/color] [color=black]e[/color] As [color=black]System.EventArgs)[/color] Handles [color=black]Button1.Click[/color]
      Dim [color=black]i[/color] As Integer
      For [color=black]i= 0[/color] To [color=black]9[/color]
          'Do something
      Next
      [color=black]MessageBox.Show(i.ToString & " Items Added???")[/color]
      For [color=black]i = 0[/color] To [color=black]4[/color]
          'Do something else
      Next
      [color=black]MessageBox.Show(i.ToString & " Items Changed???")[/color]
  [color=navy]End Sub[/color]

[x-ice]

"Rules of thumb" may be useful but sometimes you can't get people to agree upon what should be considered a rule of thumb. Sometimes s are set by the company you work with (or your boss) and that can change.


That's really confusing since what's obvious to you might not be obvious to me.


I wouldn't really call this a rule. Most IDEs do that anyway nowadays.


I know lots of people who hate WITHs. If your statement block is large, having a .SomeProperty somewhere inside the block can be confusing. Also, you can't copy-paste the .SomeProperty to the Watches window since the IDE will complain that it's inadequately qualified.

I would think that it's better to focus on more fundumental things (like "Always use meaningful names instead of TextBox1" etc).

OK, i get you, i've changed my post in response to your reply.