Codesmith vs. Hand coding

  • Thread starter Thread starter M.Siler
  • Start date Start date
M

M.Siler

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?
 
John,

If it is not there, you should write it yourself.
(Whatever way you do that by making your own classes, controls, components,
jus copying or whatever)

It will never be clever to write forever again and again the same code.
However, I will not say that one solution is the best.

Just my thought about your question.

Cor
 
"M.Siler" <[email protected]>'s wild thoughts were
released on Wed, 23 Aug 2006 08:58:46 -0400 bearing the
following fruit:
I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?
Click to expand...

Back in VB6 I always used the wizard to produce the base
code for my usercontrols. Every other wizard I'd used
produced code that was rubbish and so with that one
exception I've always coded things myself.

If the wizard saves you time then it's a good thing, but if
you end up rewritting most of it then don't bother.



Jan Hyde (VB MVP)
 
AFAIK :
- CodeSmith is a general purpose generator i.e. you can create templates
that will generate the code as YOU wish
- Wizards are creating "standard" code that is generated as is and you
generally can't customize the generation process

I tend myself to not use Wizards and would likely write some code to create
personalized source code rather than using something like CodeSmith.

But I don't think this is an all or nothing approach. Let's use what best
fit (for example I'm using of course the UI designer that after all just
creates some code, would he want to write the UI code by hand rather than
hebing the VS designer doing this for him and if he needs to code over and
over again slight variations of the same code, would he code by hand rather
than automating this code generation by using CodeSmith or his own generator
?)
 
I think code generation then customisation is good. This is the case
if a lot of your projects are similar.

I wrote my own code generation utility which from a database (SQL
Server) produces:

tableAdapter + data access layer
business objects
windows forms

I then customise these for each application, and find it really speeds
up my delveopment.
 
M.Siler said:
I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?
Click to expand...

Codesmith--like the Visual Studio IDE--is just another tool to help you work
faster and more efficiently. Your developer friend's belief that you have to
manually write all the code yourself to show that you "have real skills" is
foolish. The users of your software are not going to care what tools you
used. But they will care whether your software meets their needs and was
delivered on time and with quality. Does a carpenter lack real skills
because he chooses to use a power nail driver instead of pounding in each
nail by hand with a hammer?
 
We use strongly typed datasets and I believe was one of the big reason for
CodeSmith... this guy doesn't like the constraints strongly typed datasets
impose.
 
It seems to me that the argument is invalid. You say that the issue is
CodeSmith vs. Hand Coding. Where is it written that you must use one
exclusive of the other?

The real question is, how much should you use any tool that writes code for
you, and how much should you write by hand?

Tools that write code for you will write boiler-plate code. This is good in
some situations, and not so good in others. Because boiler-plate code is
tailored to fit a variety of needs, it is not as efficient generally in
terms of performance as hand-written code, if the hand-written code is
written well. And there is no arguing that hand-coding, if used by an
experienced developer, will yield more efficient code.

But is efficiency the only consideration? If it were, why would there be any
high-level languages? High-level languages (I'm not going to include
assembler in that category) are basically macros that perform a series of
low-level operations in a single function. So, obviously, an application
written in Assembler is going to run faster than an application written in
C, by a very small margin.

But the reason that such languages and tools exist is purely for the purpose
of increasing productivity. To write an application like Microsoft Word in
assembler would take decades. The most expensive cost factor in software
development is human salaries. And we live in a competitive world. So, you
have to strike a balance between high application performance and rapid
application development.

The argument that tools like CodeSmith produce substandard developers is
ludicrous. Substandard developers produce themselves. Each of us has a
choice to get serious about our work or not. A good, experienced developer,
like an experienced carpenter, will use the tools that enable him/her to
produce a product as quickly as possible. But a good developer will also
know when to hand code, that is, when the cost factor of hand-coding
outweighs the productivity increase that comes with using tools. And a good
developer is not affected by the quality of the tools he/she uses. The
quality of the work will always be good, but productivity may increase with
better tools.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

It takes a tough man to make a tender chicken salad.
 
Kevin Spencer said:
It seems to me that the argument is invalid. You say that the issue is
CodeSmith vs. Hand Coding. Where is it written that you must use one
exclusive of the other?

The real question is, how much should you use any tool that writes code
for you, and how much should you write by hand?

Tools that write code for you will write boiler-plate code. This is good
in some situations, and not so good in others. Because boiler-plate code
is tailored to fit a variety of needs, it is not as efficient generally in
terms of performance as hand-written code, if the hand-written code is
written well. And there is no arguing that hand-coding, if used by an
experienced developer, will yield more efficient code.

But is efficiency the only consideration? If it were, why would there be
any high-level languages? High-level languages (I'm not going to include
assembler in that category) are basically macros that perform a series of
low-level operations in a single function. So, obviously, an application
written in Assembler is going to run faster than an application written in
C, by a very small margin.

But the reason that such languages and tools exist is purely for the
purpose of increasing productivity. To write an application like Microsoft
Word in assembler would take decades. The most expensive cost factor in
software development is human salaries. And we live in a competitive
world. So, you have to strike a balance between high application
performance and rapid application development.

The argument that tools like CodeSmith produce substandard developers is
ludicrous. Substandard developers produce themselves. Each of us has a
choice to get serious about our work or not. A good, experienced
developer, like an experienced carpenter, will use the tools that enable
him/her to produce a product as quickly as possible. But a good developer
will also know when to hand code, that is, when the cost factor of
hand-coding outweighs the productivity increase that comes with using
tools. And a good developer is not affected by the quality of the tools
he/she uses. The quality of the work will always be good, but productivity
may increase with better tools.
Click to expand...

Exactly right. There are a couple guidelines that I think can be applied
though.

The idea proposed for using automated code generation to start the code
which will be customized by hand is VERY dangerous. Implemented directly,
this produces unmaintainable code.

Just as cut+paste techniques must give way to reusable libraries, so must
customization of automatically generated code be done without editing the
generated code. Use inheritance, use composition, use partial classes, but
never ever edit the generated code. Make sure that when you fix a bug in
the codegen tool, you can rerun the automated tool, not manually patch every
piece of code it created.
 
Code Generation versus Hand Coding depends on the quality of the code
produced. Either by hand or by the code generator. I can't speak for
CodeSmith as I have never tried that tool but if it can create quality code
that you can use then it is a plus. Code Generators have been around a long
time with varying degrees of success:

- I know that I would of had a much more difficult time if I could not use
Lex and Yacc in my Compiler Design class many moons ago.
- I know that most of the wizards code I found in earlier IDE's didn't quite
create code the way that I wanted to as such I didn't use them much.
- I know from a recent project that had lots of redundant code that if I had
spent 1/2 a day writing a code generator I would have been able to save a
week on development time.

Software development life cycles get shorter and shorter and the demand to
meet them increases. Good Quality software must be delivered faster and
faster. Code Generation has the benefit of making it so that you only have
to fix code in one place. With Partial Classes in .NET 2.0 that gives you
the ability to generate boilerplate code while keeping your custom code
separate. This is a great enabler of being able to generate code. You must
be able to REgenerate it without losing anything.

Just my thoughts.

Michael
 
I kind of agree and disagree, but as far as i'm concerned it's a different
argument in that case.
If you ARE going to use DataSets as the data objects in your application
then you should definately use strongly typed datasets, however if you are
still flexible with this approach i'd recommend putting some time aside to
consider using PONOs (Plain old .NET objects).

It depends on the size and scope of the project, if it's short term than
datasets and ADO.NET are probably the quickest and easiest thing to
implement, if it isn't then you will suffer from:

The Shotgun smell
-------------------
Where a change to a dataset creates a large number of changes required in
the source code. This is because if you add an additional column to a
strongly typed dataset then the definition of the "AddXXXRow" changes. A
change to a PONO does not cause this issue.

Relational code
----------------
This again depends on the project you are working on, but if you are a team
that will change in size and bring in different people at different times
then a relational model means that it takes longer to get some developers up
to speed. This is because the data objects represent the database data
better than they do the application data, meaning that the developers will
not fully understand the workings of some of the code unless they understand
the database.

Naming Issues
---------------
Different DataSets that support different properties but are similar will
have all sorts of fun names, someone may make a dataset that is identical to
another apart from one column (possible to avoid the shotgun problem) which
can make naming confusing (and naming IS important).
Also strongly typed datasets usually require longer names as the classes are
nested within each other:

E.G: Customers.CustomerRow instead of CustomerRow.

Intellisense going AWOL.
--------------------------
Dont know if they've fixed this in VS2005 but in 2003 the intellisense would
go AWOL on strongly typed datasets quite a lot, this is especially
frustrating and isn't an issues with PONOs.

I personally use PONOs with an ORM Mapper (NHibernate) as I find this helps
keep the object model tidy, clear and more easily understandable to other
developers, I can also encapsulate operations that are based purely on the
data within a given object within a method (which you can't do on generated
code as all mods get lost when re-generating, unless you use .NET 2 and
partial classes).

So I guess I agree with your colleague, although not for his reasons.
Generated code is still a powerful tool and if someone ports over the
generator from Java that creates classes based on a database or NHibernate
mapping files based on classes then i'll definately use them.

HTH
 
M.Siler said:
I'm trying to get my head around a conversation I had with a
developer the other day. We were talking about Codesmith vs. Hand
coding. He's position is Codesmith is for junior to mid level
developer who perfer "wizards" to write code for them. That these
types of code generators produce substandard developers who don't
have real skills. I don't have a position one way or the other until
I have a bit more information, but if I was to take the other point
of view... Is there value in utilizing something like Codesmith to
generate the bases of some code and then to customize it from there?
Click to expand...

Hand written:
- slow
- repetitive and thus boring
- error prone

Code generation:
- fast
- not boring (click a couple of buttons)
- no bugs, as everything is already tested before.

Now, if this developer finds himself so l33t that he needs to write
everything himself or he's no real developer, so what. YOU should use
what gets the job done, not what some short-sighted person tries to
sell you.

If he's so against code generation, how come he's not writing in IL?
After all, the code generation performed by the C# compiler (a compiler
is just a code generator after all) is for juniors, right? ;)

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
M.Siler said:
I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?
Click to expand...

Code generation is a form of abstraction and indirection. You write code
in the source language / arguments to templates / arguments to code
generator / whatever, and it produces target code, which gets processed
by other things.

There are other abstraction and indirection tools available to the
developer: delegates (functional indirection), classes (via dynamic
dispatch), interfaces (even more flexible dynamic dispatch), overloading
(compile-time dynamic dispatch), generics (abstraction and indirection
of types).

Which one is best depends on the scenario. In particular, it depends on
how close a match the problem domain is to the chosen source language.
If it's a close match for the tools provided by C#, then C# should be
chosen; if it's a close match for templates etc. or another code
generation language tool such as parser generators, then such code
generators should be chosen (if they're flexible enough).

I'd add that if you're modifying the code *by hand* after it's been
generated, it's not as useful as it might otherwise be - code generation
works best when you only work on the source side. You lose an
indirection layer when you work on the generated side, so your
modifications have less "power" as it were, and also the work is at risk
if the source language / arguments need to be changed.

-- Barry
 
The idea proposed for using automated code generation to start the code
which will be customized by hand is VERY dangerous. Implemented directly,
this produces unmaintainable code.
Click to expand...

I agree that the process of customizing generated code by hand is dangerous,
but that doesn't mean it's not useful or recommended. In fact, it is a
technique which I employ successfully from time to time. Because of the
dangers involved, it is necessary to ensure that you understand the
generated code, and how it was generated. It is not something one should do
often, but for people with the skill to do it, it can be a good productivity
tool.

But that just brings me back to my first point. A good developer should be
*able* to write the entire app by hand without any code generating tools.
That is, he/she should understand what the code generator does and be able
to do it without the code generator, before he/she uses a code generator as
a productivity tool. Once one reaches that point, code generators and
similar tools become quite helpful.

The danger lies in the very real possibility that one can write an entire
application with these tools, and know almost nothing about what one has
created. Many people take this shortcut, and find themselves over their
heads in short order.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

It takes a tough man to make a tender chicken salad.
 
M.Siler said:
I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?
Click to expand...

I would disagree. Senior developers get there by understanding and
using the tools available. That includes when and where to use them,
what the limitations are, etc. I would not depend on them, but they can
save time and effort, or not if you don't understand what they are
doing.

As an analogy already brought up, I went to rent a power nailer to
attach baseboards to drywall instead of using a hammer. The guy at the
shop told me any nailer I rented would probably drive the nails out the
back of the drywall. I ended up using a hammer.

I guess my question to the developer is: Are you using VIsual Studio?
Why not Notepad and csc? I'm sure you can find a Windows version of VI.
Maybe, if you are lucky, there might be a line editor like the one I
first used in high school. Ever hand-code a COM interface in C? Off
forum, but every developer I know uses XDoclet or similar to generate
EJB code. I have plug-ins for the Java editor that generate Hiberate
files and Java classes based on the database schema I used. I would not
want to code the classes by hand. I'm working through a tutorial on
MSDN now on datasets. I've done lots of SQL by hand, it's nice to have
a tool do some of it for me.
 
It sounds like he doesn't understand the power of code generators.

I would refer him to "Write Code that Writes Code" section of the Pragmatic
Programmer.

http://www.pragmaticprogrammer.com/ppbook/extracts/rule_list.html

The short of it is that "Code generators increase your productivity and help
avoid duplication".

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| I'm trying to get my head around a conversation I had with a developer the
| other day. We were talking about Codesmith vs. Hand coding. He's position
is
| Codesmith is for junior to mid level developer who perfer "wizards" to
write
| code for them. That these types of code generators produce substandard
| developers who don't have real skills. I don't have a position one way or
| the other until I have a bit more information, but if I was to take the
| other point of view... Is there value in utilizing something like
Codesmith
| to generate the bases of some code and then to customize it from there?
|
|
 
Me too, CodeSmith (and other such tools) are killer tools (in positive way)
in skilled hands.
They can help you soo much with tedious work that it can't be even described
:-)
 
Back
Top