Improve VBA IDE: Line numbering by default
Line numbering is essential for efficient error trapping. It would be great if the VBA had line numbering by default. To be effective, it should...
(a) automatically renumber when code is edited
(b) be able to be toggled between show/hide
Doug Ivison commented
Anybody doing Agile ... or pair programming? Line numbers are used all the time, for talking about the code you're both looking at.
And I'm with Francesco Foti: don't need Erl, don't need them to synch with debugging or error messaging, and CERTAINLY don't need to use them programmatically (have no intention of coding GOTO statements, lol) ... they're just basic (pun intended) part of coding together, peer review, etc.
(Yes, I know -- old thread -- but this is where Google is pointing, and probably not just for me!)
Ben Sacheri commented
Instead of having line numbers embedded in the code and in the way during development, I propose that the undocumented ERL be able to report the line number the same way vbWatchdog does, unless there are explicit line numbers (to be backwards compatible).
In the VBA IDE it would be nice if line numbers were outside of the code, visible in the left margin like in Notepad++, with the option to turn them on or off. It wouldn't matter to me if the line numbering were continuous throughout the module, instead of starting at 1 or 10 in each procedure. Continuous numbering would make it easier to find a reported error line without first having to find the procedure.
A bonus feature in the IDE could be a dialog to "Go To" a line number like the Go To dialog in Excel.
Hi, I have excel 2010 it is possible to turn on or add line numbering on my IDE. THANK YOU.
Francesco Foti commented
Line numbers are an important visual aid for editing code, no matter what the language is and the size of the routine. In my VBA projects, how many times have I inserted stop/resume statements in my error trap, just to see which line generated the error ? having an error line number would definitely be useful, although I wouldn't even mind if it's not reflected in an Err object property. There's nothing "old" or wrong with line numbers in a code editor, visually it's just a user preference, so toggling goes naturally with the feature. Every code editor I know of can display them including all the visual studio editions. Bring it to the VBA code editor.
Paul Rohorzka commented
Thanks Mathieu. I could not agree more.
I do not know if this would help to keep track of changes in multiprogramming environments
Mathieu Guindon commented
No, no, no, no. Line numbers are NOT useful for error trapping at all, and the undocumented Erl function is broken and only has integer resolution while line numbers can be a long.
Making VBA code default to looking like 1980 can't be the way forward, and makes line labels superfluous which is dumb. Use On Error statements with line labels, and write smaller functions. If you can't tell what threw an error, you've written a procedure that's doing too many things. Refactor your code, don't force line numbers down my throat!
A MUCH better idea would be to give VBA programmatic access to the call stack, so we could have current-century error reporting. See what vbWatchdog does.
I like it in notepad++ and better for collaboration as easier too point people somewhere.
This would be a very helpful debugging feature, especially in applications deployed long ago that suddenly come up with runtime errors.
Andy Rice commented
We need this in the VB editor for error handling!
Used line numbers in mainframe FORTRAN code 50 years ago but only because I had to. They're unnecessary or unavailable in COBOL, BAL, PL/I, Pascal, REXX, or VBA and I never missed them.
Anders Ebro (TheSmileyCoder) commented
Totally agree. I use line numbers alot, but right now its part of the deployment procedure to add line numbers, because its so disturbing to see them while developing, but they are critical while getting/logging an error message.
Juan Soto, Access MVP commented
Couldn't agree more Greg! The line number can be used in error messages to quickly identify where the error is being generated.