Why not write all of your apps as a single executable? That way you can
always reach any of the code.
Why not write all of your tables in your server as a integer field and a
text field and store XML in the text field? That way, you can change the
storage without having to change the schema.
In one of your examples, you mention creating a signature with a bool and
returning a true. You have now typed the signature as a Boolean. That means
if you really need an integer, you are changing the signature anyway, so
your advantage of creating a function over a sub is no advantage.
Perhaps then you go to a string instead. So, you pass back "true". You now
can change it to a real string, or turn your integer (internal) into a "1",
etc. Sounds promising, but you are boxing and unboxing both in your internal
code and on the other side, where the consumer has to convert the generic
string to a real type. Not wise. Now, you could retype to the proper type,
but then you have no advantage over creating a sub and changing it to a
function later.
If you want to follow "proper .NET standards" (take this with a grain of
salt, as I am not certain there are firm rules until you examine a
particular problem explicitly), you throw exceptions for exceptional
conditions, not obfuscate the condition with a false. You also have a good
idea, up front, when you are going to return values. This is not always
true, but a bit of homework up front can help you avoid massive signature
changes.
The other thing to consider is refactoring is a natural part of software
development, even if penny pinchers are convinced that things get coded once
and life goes on. If time is not entered in to refactor, you are going to
create buggier software. End of story.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************