Line Numbers in VB Code

[SajidAttar]

Hi Guys!

While writing vb programm it is not neccesarry to add line number to each line. I have observed some of programmer use to add line number in theire programms. I think this practice helps them to navigate theire programms also we can jump to any line using 'goto <Line Number>' statement.

Private Sub Command1_Click()
100     MsgBox Text1.Text
101     MsgBox Text2.Text

102     . . .
109     . . . 'no need to add line numbers in sequence
106     . . . 'but it sould be unique in its scope

End Sub

Is there any other reasons to do such? I looked in this forum and googled on web but could not get satisfactory reason and I believe you guys are having the knowledge of this practice. may be some of you are use to do this practice.

Thanks in advance,

Sajid

 

[CassandraR]

Hi Sajid:

An important use of line numbers is program debugging. If one numbers the lines and adds error handling, then one can determine which line caused the error.

For example, one could do something along the lines of

Private Sub MySub()
10    On Error Goto MyErrorHandler

    . . . .  Program code . . . .

1000  Exit Sub

MyErrorHandler:
    Debug.Print "Error Number: " & Err.Number & " occurred at line " & ERL

End Sub

Upon an error in the Program Code, VB would jump to MyErrorHandler. The Debug statement would then print the error number and error line number.


Cassie
PIII-500Mhz-128MB
Win98SE-VB6SP5

 

[SajidAttar]

Thank you Cassie. now it is clear to me.








Regards,


"There are no secrets to success. It is the result of preparation, hard work, and learning from failure." -- Colin Powell

 

[CassandraR]

You are very welcome, Sajid.


Cassie
PIII-500Mhz-128MB
Win98SE-VB6SP5

 

[chiph]

The MZTools VB6 IDE add-in has the ability to automatically line-number your code.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[BobRodes]

I've actually seen one high-quality piece of production code that numbers all the lines, and includes the number in all error messages. It actually worked out quite well with support calls, since a user with a problem would be able to relate the exact line where there was a problem.

Bob

 

[chiph]

We used them at a previous job -- it was part of the build process to add them. While I couldn't claim for it to be high-quality code, it certainly helped find bugs.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[LazyMe]

also we can jump to any line using 'goto <Line Number>' statement

This is not a very good idea. First off; using goto is considered bad practise because it makes a program even more unreadable than some already are. Second; if you absoultely must use a jump, a labeled destination would make the code a bit less unreadable than using a numbered destination, as this number can only be read at the line that actually performs a jump, whereas a labeled destination would be visible when scrolling through your code.....

While I couldn't claim for it to be high-quality code, it certainly helped find bugs.

A long time ago I worked on a project that used the same technique; each build line numbers and error handlers where automatically added. This really made debugging almost a pleasant job. But what bothered me at that time and, since I've never taken the trouble to actually investigate, still bothers me now when reading this thread is that I do not understand the impact on performance on this technique. I do not even understand the way this works with line numbers being available in compiled code (which actually is the same problem). How does the VB error handler know in a compiled situation which line of my code actually caused an error? I'd say that a compiled program looks, at best, somewhat different than my sourcefile layout? It could at least be somewhat optimized, like for instance; where I need tow-three lines of code to do something, a compiled situation might be half a line of code??

Could someone like strongm shed some light on this?

Greetings,
Rick

 

[GPOTony]

Rick,
re the effect on performance of adding line numbers, I think it's worth having a little overhead in terms of performance if it saves time in development, support and trouble-shooting.
User satisfaction is more import than optimum resource efficiency.
Tony

 

[Golom]

This company has a product called SolutionError that adds error trapping with line numbers. It does a good job and you can control how it builds the error handlers (or at least somewhat control it.)

 

[LazyMe]

Tony,

It's not so much the overhead that's bothering me; it's that I don't know how much overhead it involves, if it even does involve overhead... I just want to know how it is possible that errors can be retraced to lines of source code after having been compiled

Greetings,
Rick

 

[tsdragon]

My guess is that there is at least one line of code inserted before each of your uncompiled lines is compiled and inserted which sticks the line number into some system variable where it can be accessed by the error code.

Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Golom]

It's not really the line numbering that causes the overhead ... it's all the error-trapping code that these things insert.

Here's an example of a routine without error trapping

Public Property Let Bankable(ByVal vData As Boolean)
     mvarBankable = vData
End Property

and here it is again after the error traps have been inserted

Public Property Let Bankable(ByVal vData As Boolean)
1    Const sProcSE = msModSE & "Bankable"
2    On Error GoTo DoErrorSE
3    BeginProcSE sProcSE
4    mvarBankable = vData
5    ExitProcSE sProcSE
6    Exit Property
DoErrorSE:
7    ShowErrorSE sProcSE
8    If gbRetrySE Then
9       Resume
10    Else
11       Resume Next
12    End If
End Property

where "BeginProc", "ExitProc" and "ShowError" are routines in a module that respectively add the procedure name to a collection; remove it from the collection and display any errors that were raised. This application compiles to about 3MB without error handling code inserted and to 5.5MB with it. There is an observable speed difference but it is more than compensated for by the comprehensive handling of errors.

 

[chiph]

The code I worked on was for a website that gets 4 million hits per day. We didn't really see a performance hit by adding line numbers, and even if there had been one, being able to locate and quickly fix any bugs outweighed that by a huge factor (any downtime caused service level agreements to kick in, costing us lots of money).

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first