AG Bullet

Defensive programming
------------------------------

Assert everything, assume nothing.

From the Office on tele "Assume makes an 'ass' out of 'u' and 'me'."

Ever had that feeling, last build it all worked and now it doesn't.
Something has changed, maybe its somebody calling you or somebody your calling.
All the same it doesn't work and there is no error messages...
Maybe somebody is calling your code incorrectly or maybe somebody has changed their code.
The other person should have a clearly defined interface to their code, with only the functions that they want to accept public to you with well defined parameters. If you are sending the wrong parameters then they should give you an assertion or

exception so that you can easily find the problem, and so should you.

C++/C#:
public void Foo(string bar)
{
System.Diagnostics.Debug.Assert( bar!=null)
// Foo bar
}

or

Foo does foo stuff
expects a name
bar is null
public void Foo(string bar)
{
if( bar == null )
{
throw new ApplicationException( "Bar can't be null", new InvalidParameterException("bar") );
}
// Foo bar
}

Then to find any problems perhaps we can simply look at the event log or the trace events...

public void Foo(string bar)
{
try
{
// Foo bar (including previous parameter check and throw)
}
catch( ApplicationException ae )
{
System.Diagnostics.Trace.Write( ae.Message);
}
}

So in early development (alpha) we could just assert our assumptions, and in beta/final we can define our interface with

possible exceptions and throw them then catch them at our boundaries to realise any possible problems.

But lets look a little deeper, if we could define an object that was a non-nullable string as a parameter then the check

might just be unnecessary. Type safety as described in the last sentence, reduces the margin for error significantly, reduces

our need for checks, and catches errors at compile time. So in defensive coding terms it might just be a good thing.

Lets look at another example:

void AddItemToBasket( string entryType, string barCode )
{
System.Diagnostics.Assert( entryType=="KY" || entryType=="SW" ); // for non-programmers || means or
System.Diagnostics.Assert( isBarcode( barCode) );

// do stuff
}

An easier (type safe) way might just be this:

enum EntryType {
Keyboard, // "KY"
SwipeCard // "SW"
}

void AddItemToBasket( EntryType entryType, Barcode barCode )
{
// do stuff
}

// posted by Phil @ 1/14/2004 01:53:00 AM

"High level languages increase productivity"

C gave us for, while, switch statements with similar speed to assembler but with a degree of platform neutrality, and the basis of such products as Unix, Linux, Mac OS and Windows.
C also gave us higher productivity through simpler syntax, easier maintainence (more products like word processors, spread sheets and even used in games), and then led us on to yet higher thoughts.
Then C plus plus gave this world the low level advantages of C with OOP (object orientated programming) concepts built-in promoting objects and reuse through abstraction, inherithance (single and multiple) and polymorphism.
A brave new world where the programmer could mix low level and high level code in the same breath and produce high performing applications.
At the same time the BASIC languages (Beginners All-Purpose Symbolic Instruction Code) gathered pace with its easily learnt reduced functionality.
Then along came Java, a cut down version of C plus plus removing the low level portion (pointers), multiple inheritance and constant correctness. Some less experienced coders (bless 'em) had encountered errors understanding some of these concepts so by removing these potential problems (advanced stuff) the language was seen as "safer" and "less error-prone".
C sharp from Microsoft is much closer to Java than it is to C or C plus plus.
So Java and C# have removed some of the more advanced features of earlier high level languages as designed in the early 80s on Eiffel and C plus plus but have still not managed to avoid poor coders who can still continue to use globals or produce functions consisting of 1,000 plus lines of code (excuse my synacism.)

I propose a silver bullet, now that everybody uses an IDE to compile their code, that there is an experience level set in there (.Net people think FXCop now, but lets kill/catch it at write/design time). If you are inexperienced then you should not be allowed to compile code that has a function over 30 lines of code (any other level you probably wouldn't want to do this too often anyway), if you are intermideate level then you are allowed to use inherthance (has a or is a, to be or not to be), and if you are advanced then you are allowed to consider and use multiple inherithance and if you so wish for performance, flame me if you will pointers, const correctness and type safety. (There should probably be some sort of accreditation that goes with these levels, e.g. 1 years, 3 years, 7 years rather than randomly calling youself senior because?)...

It seems logical if you couldn't be trusted with high level concepts then BASIC it was, if you could then C/C++ was your language. Now the lines are blurred, they always have been and don't get me wrong I encourage people to cross over, but as the languages have shown there are different strokes for diffent folks. Product Widget26 may well be better written in Visual Basic, this widget is not a world beater it has just got to do X, Y, Z (there will always be a place for this). Still this is not why I and some others are here for, its about Widget2005 needs to do XYZ plus plus and change the whole way people think about X, Y, Z, T (please look at n-dimensional math). We all started somewhere and we should all strive to get better? (I started programming assembler and BASIC so why should I think that somebody of similar or even a different background should move on to more high level (or low level) stuff, as you can see I don't(?).)

For those who still don't believe that capable people can't be trusted please think about the start of this blog (Unix, forget the others), then think what was the Oracle database or Microsft SQL Server written in (doh!). If you are not about to flame and remotely interested on how C plus plus can do what it does (and by the way compile immediately to .Net IL) without leaking and using pointers then please search out Resource Managament on google and then consider why there is a "finally" statement in C sharp...

Finally we shall go backwards, nobody should be trusted with programming languages, any advances for more advanced users should now be removed because less able users may misinterpret them (doh!). Maybe its time to read/write "Dumbies guide to...", or "Calculus in 24 hours", sure!

Retirement plan

Today I am 32 at the end of 2037 I will be 64++, if 2000 is anything to go by, this should be a cash bonanza year, forget your pension...

MFC Time - thanks Microsoft
Thanks to Unix also

Will there still be C code running in 2037, thats years away? Was there Cobol code from the 70s running in 2000? Yes! Lots of it, it still works, if it ain't broke don't fix it... and its probably more stable than todays code... damn it runs really quick too...

If your not of potential retirement age at this time, don't worry you can still cash in, and believe me there could be another one on the horizon not much more than a decade after...

Oh no, SelectSingleNode is evil!

If you want to get a child element by tag name don't use an XPath statement, use the indexor:

1. XmlNode item = node.SelectSingleNode( "tagname" );
2. XmlNode item = node["tagname"];

Hint: could have been solved with a Strategy pattern...

.Net framework free stuff links

Source code:
Anakrino decompiler - take a look at the .Net Framework source
Mono - an open source implementation of the .Net framework
DotGnu - and another one

Tools:
#Develop - C# IDE
NUnit - Unit testing framwork and TestRunner
NAnt - Build tool
NDoc - Get docs just like MSDN from your C# Xml comments
FXCop - code analysis tool

Information:
Design Guidelines for Class Library Developers - naming conventions
Design patterns - GoF design patterns with C# examples
Microsoft patterns - .Net specific patterns
Exception Management Architecture Guide - try and catch

Stuff worth considering paying for

C# Refactory - refactor with ease
Ants profiler - find where your performance is going