Home |
Search |
Today's Posts |
#1
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
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 |
#2
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
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 |
#3
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
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 |
#4
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
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 |
#5
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
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 |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
Best Practices (Counter) | Excel Discussion (Misc queries) | |||
Comparing Spreadsheets - best practices | Excel Discussion (Misc queries) | |||
Best Practices Question | Excel Programming | |||
Task pane best practices | Excel Programming | |||
best practices question | Excel Programming |