Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 345
Default 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
  #2   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 9,101
Default 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

  #3   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 897
Default 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


  #4   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 345
Default 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

  #5   Report Post  
Posted to microsoft.public.excel.programming
external usenet poster
 
Posts: 345
Default 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



Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best Practices (Counter) Dax Arroway Excel Discussion (Misc queries) 3 December 18th 08 01:47 AM
Comparing Spreadsheets - best practices James Excel Discussion (Misc queries) 1 March 15th 08 02:01 PM
Best Practices Question Barb Reinhardt Excel Programming 6 November 28th 07 11:28 PM
Task pane best practices Josh Sale Excel Programming 0 July 3rd 07 09:10 PM
best practices question Gary Keramidas Excel Programming 3 March 22nd 06 10:11 AM


All times are GMT +1. The time now is 02:19 PM.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 ExcelBanter.
The comments are property of their posters.
 

About Us

"It's about Microsoft Excel"