VBA Continuation Lines, Best Practices Mar08
 

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

VBA Continuation Lines, Best Practices Mar08
 

I use continuation lines for a few reasons

1) When posting code on this website so errors aren't generated when people
copy the code. This website automatically adds a carriage return after 80
characters. If this is in the middle of an insttruction an error will be
generated when the code is pasted into VBA

2) I add a continue line so I can sse all the code in the VBA window without
having to scroll to the right.

3) I add a continuation line to make the code easier to read.

This is the code when you record a macro in excel for a SORT

Range("E4:G8").Select
Selection.Sort Key1:=Range("E4"), Order1:=xlAscending, Header:=xlGuess, _
OrderCustom:=1, MatchCase:=False, Orientation:=xlTopToBottom, _
DataOption1:=xlSortNormal

I usually change this code to the following

Range("E4:G8").Sort _
Key1:=Range("E4"), _
Order1:=xlAscending, _
Header:=xlGuess, _
OrderCustom:=1, _
MatchCase:=False, _
Orientation:=xlTopToBottom, _
DataOption1:=xlSortNormal

"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

VBA Continuation Lines, Best Practices Mar08
 

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

VBA Continuation Lines, Best Practices Mar08
 

Thanks Joel,
It sure is a toss up. My only other thought is 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
--
Neal Z


"Joel" wrote:

I use continuation lines for a few reasons

1) When posting code on this website so errors aren't generated when people
copy the code. This website automatically adds a carriage return after 80
characters. If this is in the middle of an insttruction an error will be
generated when the code is pasted into VBA

2) I add a continue line so I can sse all the code in the VBA window without
having to scroll to the right.

3) I add a continuation line to make the code easier to read.

This is the code when you record a macro in excel for a SORT

Range("E4:G8").Select
Selection.Sort Key1:=Range("E4"), Order1:=xlAscending, Header:=xlGuess, _
OrderCustom:=1, MatchCase:=False, Orientation:=xlTopToBottom, _
DataOption1:=xlSortNormal

I usually change this code to the following

Range("E4:G8").Sort _
Key1:=Range("E4"), _
Order1:=xlAscending, _
Header:=xlGuess, _
OrderCustom:=1, _
MatchCase:=False, _
Orientation:=xlTopToBottom, _
DataOption1:=xlSortNormal

"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

VBA Continuation Lines, Best Practices Mar08
 

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