|
xxx
Utility Belt:
FAQ: Won't using Utility Belt reduce my skill and
knowledge and become a crutch?
by Charles Carroll
A common misconception at first
glance at UtilityBelt (UB) library is that using it rather than writing your own
code will contribute to learning .net programming less thoroughly. That is based
on the following assumptions:
-
As a typical example, when one calls
a 1 line UB Method/Sub/function and it does a task one never learns how to do
the task without the one liner.
-
The dependency between your code and
UB means you are at mercy of the UB programmer and ongoing revisions.
-
UB is the kind of library only a
novice or new programmer uses and is quickly outgrown. After attaining a
certain level of skill at programming or aspiring to become a great programmer
there is little reason to start or continue using UB.
-
One learns more copying code out of
books and magazines and websites and understanding them and modifying them
than using a Library someone else made.
I will say that those assumptions
are easily refuted and just not correct although they certainly seem legitimate
at first glance.
Assumption: when one calls a 1
line UB Method/Sub/function and it does a task one never learns how to do the
task without the one liner.
Refute #1: The source code
for UB is readily available. If one calls a function it usually only results in
about a half dozen internal calls. Reading those internal calls makes it easy
to see how to code such things the correct and best way. When someone new
writes incomplete or inefficient code or code lacking error trapping and logging
- if it runs at all they are happy and they rarely build the best way. There is
much to learn about the best code by reading the UB code. In fact
options("TraceSimple=on")
will give one exactly the internal sequence called to simplify knowing what code
to read.
Refute #2: Code reuse is
vital to your career. Even if you decide to not use UB you should be in some
form achieving code reuse. Frequent use of UB shows the new programmer a
profound thing - that most code blocks of 6-12 lines can be reduced to 1 line by
refactoring. Writing 6-12 lines and minimal error handling and logging that
could have been reduced to one is a horrible habit. UB shows a good habit for
the coding issues it solves to set an example of how a novice should be
encapsulating all reusable code.
Assumption: Making your app
depend on UB ensures you are at the mercy of future UB versions and revisions.
Refute #1: Not using
UtilityBelt means you are at mercy of how carefully you wrote your code. Most
beginners make some pretty big mistakes because the code they get from books and
websites and magazine articles is not very robust. It tends to leak resources or
not free them quick enough and usually not only does not have Try/Catch blocks,
and it does not recover from unusual runtime disasters well. It lacks profiling
and logging of success and failure.
Refute #2: No one will force
you to upgrade your UB and no one will stop you from gutting UB for the code you
need and forking it in different directions. Although we recommend inheritance
rather than forking.
Assumption: UB is the kind of
library only a novice or new programmer uses and is quickly outgrown.
Refute #1: The truth is the
opposite. Beginners that are writing incorrect code copied from Googling the web
or from a book rather than using and studying the best reusable code written by
co-workers or obtained from reputable source are perpetuating "not invented
here" habits - i.e. "If I did not code it personally or copy it personally (even
if I did a mediocre or flawed job) I am not using someone else's code".
Refute #2: Experienced
programmers should be creating their equivalent of UtilityBelt or using
libraries created by others. When studying the amount of time needed to code an
application, a few hours and days choosing good library can save weeks and
months of coding. Even if one decides a library is not suitable or too limited
after a month or two working with it the library can easily be replaced and/or
fixed much more readily than starting whole library from scratch.
Assumption: One learns more
copying code out of books and magazines and websites and understanding them and
modifying them than using a Library someone else made.
Refute #1: Unfortunately most
code in books and magazines lack Try/Catch/Finally error-handling, optimization
techniques, logging of success and failure diagnostic/profiling info, and have
not been been tested for concurrency/scalability using Load Testing tools, While
such code could be placed on your website seemingly without incident .... The
fact is that since runtime errors are neither reported nor logged the times your
users encounter bizarre runtime errors or failure to run under high load you
newer know although the user had a bad experience you are given no notification
that a problem needs to be fixed.
Refute #2: Copying code
rather than encapsulating it is the beginning of a disease. We want new ASP.net
programmers to encapsulate any code they got out of books and magazines into
reusable methods and functions. Then when one discovers any GC or other code
flaws there is one place to fix it. UB demonstrates this first hand.
 |  |  |
|
There are many worthy charities!!. But perhaps help starving children in Africa or South America AND help Charles too.
a $5 tip buys him lunch at McDonalds,
a $20 tip buys his kid Hitoshi a new computer game,
a $39 tip buys his daughter Michiko a few nice outfits.
See our donor list.
| |
 | |  |
|
|
|
|