Where to store and document methods

[Ranginald]

Hi,

I am generally new to OOP and in learning and writing code I have
developed many of my own reusable methods.

A. What is the best way to store these methods for easy reuse later?
I was thinking:
1. Word document (e.g. create a "code reference book")
2. create .DLLs to store related methods


B. Is there a program that will help me manage and catalog my
code?...some kind of library for code?

Thanks!
Rangy

 

[Greg Young]

A: Store the related methods in .dlls ... there is a fundamental flaw in the
"code reference book" methodology. Lets say you have created 27 applications
using function Bar() out of your word document, in fixing application 6 you
find a bug in Bar() ... How do you update all of the other apps? (copy/paste
copy/paste .. etc) Unfortunately you may have made some app specific changes
to Bar() in application 9 ... this is a common anti-pattern "Copy and Paste
reuse" http://en.wikipedia.org/wiki/Copy_and_paste_programming

B: Try using XML Documentation combined with nDoc ..
http://msdn.microsoft.com/msdnmag/issues/02/06/XMLC/ it will allow you to
build MSDN style help files (and helps to organize your code )

Cheers,

Greg Young

 

[Jeff Gaines]

I am generally new to OOP and in learning and writing code I have
developed many of my own reusable methods.

A. What is the best way to store these methods for easy reuse later?
I was thinking:
1. Word document (e.g. create a "code reference book")
2. create .DLLs to store related methods

I am still struggling with this, I go back and forth between DLL's and
links to files.

What I have now is a Library folder with sub-folders for stand-alone
controls and a sub-folder for my main library file/class. I then add a
link to the needed files for new projects, it's easier to maintain than
re-building a DLL very time you update something.

 

[Lucian Wischik]

B. Is there a program that will help me manage and catalog my
code?...some kind of library for code?

I've found the most helpful thing is to write up the solution as a
tutorial/article and submit it to CodeProject. That way,

(1) you get thousands of other developers using it and finding bugs in
it and often helping you fix them
(2) it will survive a hard disk crash
(3) it's indexed and searchable by google and by the "search" button
in the downloadable MSDN
(4) you end up making it more robust, more reusable and
better-packaged

but most importantly

(5) you get to help people, and give back something for the help you
yourself have obtained!

 

[Bob Grommes]

Hi Rangy,

If it's general purpose utility methods you're talking about, I normally
put those in classes organized by operation type and make the methods
all static. For example you might have a Utils project containing
StringUtil and DateUtil classes, etc., and then call these methods in
your code as StringUtil.IsAllDigits(), and such.

If you are hesitant about doing this then it may be that these methods
are not sufficiently general purpose to get such treatment, and need to
be stored in libraries specific to an application domain or even an
individual application. Or, the routines may need refactoring to make
them more generally useful; they may be tightly coupled to application
data or something of that nature.

Copying and pasting routines is never a good idea; it is a maintenance
nightmare and, as someone else suggested, a best practices antipattern.
I fear that the snippet managers people are starting to use may
encourage this kind of thing, and that would not be good. Of course,
there arguably are *appropriate* uses for copy and paste, such as
providing code templates that aren't runnable as-is and need situational
logic added to them; but even then, if you find a bug in the template
you still lack a single place where you can have any changes applied to
all your existing applications. I would rather see a true templating
mechanism with a code generator for that sort of thing; that way, if the
code generation is part of the build process, then corrections or
improvements to the code template will still propagate throughout all
your systems.

--Bob