I'm learning to write pseucocode before I do the actual code as I was
taught to do in a VBA class. I've been playing with different software in
which to write it. I've tried WordPad and Notepad. Wordpad seems a little
better because I have more control of the tabs and some of the other
formatting, but I can't indent or outdent multiple lines of code. I'm sure
Word would drive me nuts by trying to force some kind of formatting it's
designed to do, like normal paragraphs or lists or outlines.

What do people use? Can you give me the benefits/issues with it? Or is it
just whatever you had at hand?

Thanks in advance.

Why bother with pseucocode, write directly into a module in a workbook's
project and test it. Just ensure you have no unsaved data.

As for indenting install Stephen Bullen's "Smart Indenter"

http://www.oaltd.co.uk/Excel/Default.htm

Regards,
Peter T

"salgud" wrote in message
.. .
I'm learning to write pseucocode before I do the actual code as I was
taught to do in a VBA class. I've been playing with different software in
which to write it. I've tried WordPad and Notepad. Wordpad seems a little
better because I have more control of the tabs and some of the other
formatting, but I can't indent or outdent multiple lines of code. I'm sure
Word would drive me nuts by trying to force some kind of formatting it's
designed to do, like normal paragraphs or lists or outlines.

What do people use? Can you give me the benefits/issues with it? Or is it
just whatever you had at hand?

Thanks in advance.

It is not clear what the problem/issue is?
You can just open a new workbook and insert a module and type away.
You can copy and paste the completed code into Word or Notepad if desired.
You can also export the module to a folder if you want to keep the module.
(right-click the module in the project window for options)
You can insert as many modules in a workbook as you want.
They all go away when the workbook closes. (unless you save the workbook)
Also, xl2007 doesn't have it, but there is Microsoft Script Editor available on
the Tools menu (you may have to install it).
--
Jim Cone
Portland, Oregon USA



"salgud"
wrote in message
I'm learning to write pseucocode before I do the actual code as I was
taught to do in a VBA class. I've been playing with different software in
which to write it. I've tried WordPad and Notepad. Wordpad seems a little
better because I have more control of the tabs and some of the other
formatting, but I can't indent or outdent multiple lines of code. I'm sure
Word would drive me nuts by trying to force some kind of formatting it's
designed to do, like normal paragraphs or lists or outlines.

What do people use? Can you give me the benefits/issues with it? Or is it
just whatever you had at hand?

Thanks in advance.

On Feb 18, 1:20*pm, salgud wrote:
I'm learning to write pseucocode before I do the actual code as I was
taught to do in a VBA class. I've been playing with different software in
which to write it. I've tried WordPad and Notepad. Wordpad seems a little
better because I have more control of the tabs and some of the other
formatting, but I can't indent or outdent multiple lines of code. I'm sure
Word would drive me nuts by trying to force some kind of formatting it's
designed to do, like normal paragraphs or lists or outlines.

What do people use? Can you give me the benefits/issues with it? Or is it
just whatever you had at hand?

Thanks in advance.

I agree with Peter that if you are actually typing you might as well
use the VBA editior. I do find it helpful to write pseudocode before
coding (especially for larger programs), but when I do it is always
hand-written since it is for my own consumption anyway and hand-
writing lends itself to things like doodling what an array or
spreadsheet layout looks like at a certain point in code execution,
jotting down marginal notes and drawing arrows to depict
dependencies.

If you like the idea of something more formal, perhaps you could type
pseudocode in a code module (with syntax-checking temporarily turned
off) then comment out the pseudocode (which can be done instantly) and
use it as a guide to write the code immediately below. I could see how
that might be helpful even if it is a bit too formalized for my taste.
It would serve a documentation purpose by giving comments which
outline the algorithm to be implemented.

hth

-scattered

On Wed, 18 Feb 2009 19:10:47 -0000, Peter T wrote:

Why bother with pseucocode, write directly into a module in a workbook's
project and test it. Just ensure you have no unsaved data.

As for indenting install Stephen Bullen's "Smart Indenter"

http://www.oaltd.co.uk/Excel/Default.htm

Regards,
Peter T

"salgud" wrote in message
.. .
I'm learning to write pseucocode before I do the actual code as I was
taught to do in a VBA class. I've been playing with different software in
which to write it. I've tried WordPad and Notepad. Wordpad seems a little
better because I have more control of the tabs and some of the other
formatting, but I can't indent or outdent multiple lines of code. I'm sure
Word would drive me nuts by trying to force some kind of formatting it's
designed to do, like normal paragraphs or lists or outlines.

What do people use? Can you give me the benefits/issues with it? Or is it
just whatever you had at hand?

Thanks in advance.

Thanks for your reply. In answer to your question, I have found that in
most things that are even a little bit complicated, come out better when I
plan them instead of just jump in and "do". I know, I'm unAmerican. But my
experience as a Project Manager is that the time it takes to plan is more
than saved in execution.

On Wed, 18 Feb 2009 11:26:15 -0800, Jim Cone wrote:

It is not clear what the problem/issue is?
You can just open a new workbook and insert a module and type away.
You can copy and paste the completed code into Word or Notepad if desired.
You can also export the module to a folder if you want to keep the module.
(right-click the module in the project window for options)
You can insert as many modules in a workbook as you want.
They all go away when the workbook closes. (unless you save the workbook)
Also, xl2007 doesn't have it, but there is Microsoft Script Editor available on
the Tools menu (you may have to install it).

Thanks! See reply to Peter above.

On Wed, 18 Feb 2009 11:34:30 -0800 (PST), scattered wrote:

On Feb 18, 1:20*pm, salgud wrote:
I'm learning to write pseucocode before I do the actual code as I was
taught to do in a VBA class. I've been playing with different software in
which to write it. I've tried WordPad and Notepad. Wordpad seems a little
better because I have more control of the tabs and some of the other
formatting, but I can't indent or outdent multiple lines of code. I'm sure
Word would drive me nuts by trying to force some kind of formatting it's
designed to do, like normal paragraphs or lists or outlines.

What do people use? Can you give me the benefits/issues with it? Or is it
just whatever you had at hand?

Thanks in advance.

I agree with Peter that if you are actually typing you might as well
use the VBA editior. I do find it helpful to write pseudocode before
coding (especially for larger programs), but when I do it is always
hand-written since it is for my own consumption anyway and hand-
writing lends itself to things like doodling what an array or
spreadsheet layout looks like at a certain point in code execution,
jotting down marginal notes and drawing arrows to depict
dependencies.

If you like the idea of something more formal, perhaps you could type
pseudocode in a code module (with syntax-checking temporarily turned
off) then comment out the pseudocode (which can be done instantly) and
use it as a guide to write the code immediately below. I could see how
that might be helpful even if it is a bit too formalized for my taste.
It would serve a documentation purpose by giving comments which
outline the algorithm to be implemented.

hth

-scattered

Thanks! See reply to Peter above.

On Wed, 18 Feb 2009 11:34:30 -0800 (PST), scattered
wrote:


If you like the idea of something more formal, perhaps you could type
pseudocode in a code module (with syntax-checking temporarily turned
off) then comment out the pseudocode (which can be done instantly) and
use it as a guide to write the code immediately below. I could see how
that might be helpful even if it is a bit too formalized for my taste.
It would serve a documentation purpose by giving comments which
outline the algorithm to be implemented.

That's the way I do it. ( I have syntax checking turned off permanently.) I
write the pseudo code as comments in the module (actually in the Sub End Sub
stub where the actual code will live) by typing the apostrophe first. Then
I fill in the actual code, leaving the pseudo code there as a comment if
it's useful. Most of it isn't useful - it's a great guide, but the end
result usually ends up different enough that the pseudocode would just be
misleading.
--
Dick Kusleika
Microsoft MVP-Excel
http://www.dailydoseofexcel.com

On Wed, 18 Feb 2009 21:14:15 -0600, Dick Kusleika wrote:

On Wed, 18 Feb 2009 11:34:30 -0800 (PST), scattered
wrote:


If you like the idea of something more formal, perhaps you could type
pseudocode in a code module (with syntax-checking temporarily turned
off) then comment out the pseudocode (which can be done instantly) and
use it as a guide to write the code immediately below. I could see how
that might be helpful even if it is a bit too formalized for my taste.
It would serve a documentation purpose by giving comments which
outline the algorithm to be implemented.

That's the way I do it. ( I have syntax checking turned off permanently.) I
write the pseudo code as comments in the module (actually in the Sub End Sub
stub where the actual code will live) by typing the apostrophe first. Then
I fill in the actual code, leaving the pseudo code there as a comment if
it's useful. Most of it isn't useful - it's a great guide, but the end
result usually ends up different enough that the pseudocode would just be
misleading.

Thanks for your reply. I have syntax checking permanently off also - what a
PITA! Might try your method- I'm just feeling my way along and have felt
that I'm trying to do too much in one step by just sitting down and writing
code. When my VBA instructor suggested I break up the process by doing
pseudocode, then a flow diagram, then the code, it made sense to me. I'm
just now trying it out, and it seems to be flowing much better and I think
the total time start to finish will be less because there'll be less going
back and rework. That's been my experience with most everything else I've
learned to plan out first. Not a common approach in the Western world, but
every study I've ever seen validates it as faster and cheaper with better
results. So I'm guessing it'll work with writing VBA code too.

On Feb 19, 6:48*pm, salgud wrote:
On Wed, 18 Feb 2009 21:14:15 -0600, Dick Kusleika wrote:
On Wed, 18 Feb 2009 11:34:30 -0800 (PST), scattered
wrote:

If you like the idea of something more formal, perhaps you could type
pseudocode in a code module (with syntax-checking temporarily turned
off) then comment out the pseudocode (which can be done instantly) and
use it as a guide to write the code immediately below. I could see how
that might be helpful even if it is a bit too formalized for my taste.
It would serve a documentation purpose by giving comments which
outline the algorithm to be implemented.

That's the way I do it. ( I have syntax checking turned off permanently..) *I
write the pseudo code as comments in the module (actually in the Sub End Sub
stub where the actual code will live) by typing the apostrophe first. *Then
I fill in the actual code, leaving the pseudo code there as a comment if
it's useful. *Most of it isn't useful - it's a great guide, but the end
result usually ends up different enough that the pseudocode would just be
misleading.

Thanks for your reply. I have syntax checking permanently off also - what a
PITA! Might try your method- I'm just feeling my way along and have felt
that I'm trying to do too much in one step by just sitting down and writing
code. When my VBA instructor suggested I break up the process by doing
pseudocode, then a flow diagram, then the code, it made sense to me. I'm
just now trying it out, and it seems to be flowing much better and I think
the total time start to finish will be less because there'll be less going
back and rework. That's been my experience with most everything else I've
learned to plan out first. Not a common approach in the Western world, but
every study I've ever seen validates it as faster and cheaper with better
results. So I'm guessing it'll work with writing VBA code too.- Hide quoted text -

- Show quoted text -

You have a good attitude. I suspect that it will pay-off with programs
that require less debugging the first time around. You might enjoy the
book "Code Complete" by Steve McConnell. It is one of the few computer
books I've read cover to cover and wanted to read over again
afterwards. It contains a wealth of practical suggestions for writing
good software. See http://cc2e.com/ for reviews and a sample chapter.

hth

-scattered

Looks like I misinterpreted what you meant by pseucocode

Regards,
Peter T

"Peter T" <peter_t@discussions wrote in message
...
Why bother with pseucocode, write directly into a module in a workbook's
project and test it. Just ensure you have no unsaved data.

As for indenting install Stephen Bullen's "Smart Indenter"

http://www.oaltd.co.uk/Excel/Default.htm

Regards,
Peter T

"salgud" wrote in message
.. .
I'm learning to write pseucocode before I do the actual code as I was
taught to do in a VBA class. I've been playing with different software in
which to write it. I've tried WordPad and Notepad. Wordpad seems a little
better because I have more control of the tabs and some of the other
formatting, but I can't indent or outdent multiple lines of code. I'm
sure
Word would drive me nuts by trying to force some kind of formatting it's
designed to do, like normal paragraphs or lists or outlines.

What do people use? Can you give me the benefits/issues with it? Or is it
just whatever you had at hand?

Thanks in advance.

On Thu, 19 Feb 2009 16:48:09 -0700, salgud wrote:



Thanks for your reply. I have syntax checking permanently off also - what a
PITA! Might try your method- I'm just feeling my way along and have felt
that I'm trying to do too much in one step by just sitting down and writing
code. When my VBA instructor suggested I break up the process by doing
pseudocode, then a flow diagram, then the code, it made sense to me. I'm
just now trying it out, and it seems to be flowing much better and I think
the total time start to finish will be less because there'll be less going
back and rework. That's been my experience with most everything else I've
learned to plan out first. Not a common approach in the Western world, but
every study I've ever seen validates it as faster and cheaper with better
results. So I'm guessing it'll work with writing VBA code too.

Yeah, my method is good for a single function, but not for a whole
application. I guess that's an important distinction to make. In that
vein, I don't map out my entire application before coding, but it sounds
like the proper thing to do.

I second scattered's recommendation of Code Complete. Professional Excel
Development is another good one.
http://www.dailydoseofexcel.com/dail...cel-book-list/

--
Dick Kusleika
Microsoft MVP-Excel
http://www.dailydoseofexcel.com

On Fri, 20 Feb 2009 14:08:25 -0600, Dick Kusleika wrote:

On Thu, 19 Feb 2009 16:48:09 -0700, salgud wrote:



Thanks for your reply. I have syntax checking permanently off also - what a
PITA! Might try your method- I'm just feeling my way along and have felt
that I'm trying to do too much in one step by just sitting down and writing
code. When my VBA instructor suggested I break up the process by doing
pseudocode, then a flow diagram, then the code, it made sense to me. I'm
just now trying it out, and it seems to be flowing much better and I think
the total time start to finish will be less because there'll be less going
back and rework. That's been my experience with most everything else I've
learned to plan out first. Not a common approach in the Western world, but
every study I've ever seen validates it as faster and cheaper with better
results. So I'm guessing it'll work with writing VBA code too.

Yeah, my method is good for a single function, but not for a whole
application. I guess that's an important distinction to make. In that
vein, I don't map out my entire application before coding, but it sounds
like the proper thing to do.

I second scattered's recommendation of Code Complete. Professional Excel
Development is another good one.
http://www.dailydoseofexcel.com/dail...cel-book-list/

Thanks to both of you. I'll take a look at both books - been thinking about
getting another one about programming anyway, so those will be good leads
for me to follow.