Thanks JP,
It sure is a toss up. My only other thoughts are that when debugging
while stepping thru the code, VBA does not allow you to add or detract from a
continued line, however you can change a whole line.

Glad to hear it's only a mild efficiency detraction for continued lines.

Readability, If I have a long line, I'll copy it to a NotePad window
and NotePad 'wraps' the line onto the screen. Sure would be nice if the VBE
editor could look @ a continued line as one.

Thanks again.
--
Neal Z


"JP" wrote:

There is a mild trade-off in readability vs. efficiency. The compiled
code is *slightly* more efficient when you leave it all on one line,
but it's more readable if you split it. My recommendation is to split
as needed, after all, you are the one that has to work with the code
so do what is comfortable for you.


HTH,
JP

On Mar 11, 12:06 am, Neal Zimm wrote:
Hi All,

Sub RowCol_vCellId(CellId As String, Row As Long, Col As Integer, _
Optional bShowMsgPrompt As Boolean = False)

Above is just an example of a continued Sub stmt. During development to
keep from scrolling left and right to see a whole statement I often break
them up. Then, you lose some capability when using VBE to find 'something'
since it doesn't "know" from continued lines.

Is there a "best" or is it a personal preferance ?

What are the other pro's/con's leaving continued lines in a proc once
the code is deemed production ready ? (For maintenance I envision replacing
whole procs, not adding or inserting groups of lines.)

Thanks,
Neal Z.

--
Neal Z