Friday, March 19, 2004
What's wrong with this code?
MSDN: .NET Framework Class Library -> DataTable.PrimaryKey Property
private void SetPrimaryKeys(){
// Create a new DataTable and set two DataColumn objects as primary keys.
DataTable myTable = new DataTable();
DataColumn[] keys = new DataColumn[2];
DataColumn myColumn;
// Create column 1.
myColumn = new DataColumn();
myColumn.DataType = System.Type.GetType("System.String");
myColumn.ColumnName= "FirstName";
// Add the column to the DataTable.Columns collection.
myTable.Columns.Add(myColumn);
// Add the column to the array.
keys[0] = myColumn;
// Create column 2 and add it to the array.
myColumn = new DataColumn();
myColumn.DataType = System.Type.GetType("System.String");
myColumn.ColumnName = "LastName";
myTable.Columns.Add(myColumn);
// Add the column to the array.
keys[1] = myColumn;
// Set the PrimaryKeys property to the array.
myTable.PrimaryKey = keys;
}
As per the first link, the replies mostly complain about context, but lets dig a little.
myTable? myColum?
Why System.Type.GetType("System.String")? Why not typeof(System.String)?
Here is another example...
DataTable personTable = new DataTable(); // please why can't I just say DataTable person; as I would in C++
DataColumn firstName = new DataColumn(); // same again
firstName.ColumnName = "FirstName"; // why not use the constructor overloads?
firstName.DataType = typeof(System.String); // why would I call a function and make it look up a string?
DataColumn secondName = new DataColumn("SecondName", typeof(string) );
// damn could have used constructor overload from the start
personTable.PrimaryKeys = new DataColumn[] { firstName, secondName }; // Hello, arrays
So looks like the MSDN examples are really setting people up well...
Even better why not use first and second names for primary keys, identities are so last year?
MSDN: .NET Framework Class Library -> DataTable.PrimaryKey Property
private void SetPrimaryKeys(){
// Create a new DataTable and set two DataColumn objects as primary keys.
DataTable myTable = new DataTable();
DataColumn[] keys = new DataColumn[2];
DataColumn myColumn;
// Create column 1.
myColumn = new DataColumn();
myColumn.DataType = System.Type.GetType("System.String");
myColumn.ColumnName= "FirstName";
// Add the column to the DataTable.Columns collection.
myTable.Columns.Add(myColumn);
// Add the column to the array.
keys[0] = myColumn;
// Create column 2 and add it to the array.
myColumn = new DataColumn();
myColumn.DataType = System.Type.GetType("System.String");
myColumn.ColumnName = "LastName";
myTable.Columns.Add(myColumn);
// Add the column to the array.
keys[1] = myColumn;
// Set the PrimaryKeys property to the array.
myTable.PrimaryKey = keys;
}
As per the first link, the replies mostly complain about context, but lets dig a little.
myTable? myColum?
Why System.Type.GetType("System.String")? Why not typeof(System.String)?
Here is another example...
DataTable personTable = new DataTable(); // please why can't I just say DataTable person; as I would in C++
DataColumn firstName = new DataColumn(); // same again
firstName.ColumnName = "FirstName"; // why not use the constructor overloads?
firstName.DataType = typeof(System.String); // why would I call a function and make it look up a string?
DataColumn secondName = new DataColumn("SecondName", typeof(string) );
// damn could have used constructor overload from the start
personTable.PrimaryKeys = new DataColumn[] { firstName, secondName }; // Hello, arrays
So looks like the MSDN examples are really setting people up well...
Even better why not use first and second names for primary keys, identities are so last year?
Wednesday, March 17, 2004
Last weekend I ended up getting a call at 9.30pm on Saturday night, and as I was at the pub took pity on my manager and his need for a stable release for Monday.
Spent the whole of Sunday tracking down a fundamental flaw in the code, a nice side effect, a get that did a set...
Book of the week
Spent the whole of Sunday tracking down a fundamental flaw in the code, a nice side effect, a get that did a set...
Book of the week
Friday, February 27, 2004
Again I have been asked to work the weekend (with the incentive of pizza).
Today was a day designated by the TUC where workers were supposed to show their employers the value of unpaid overtime by leaving early.
Any way todays e-mail answer to the work weekend concept was courtesy of a chain e-mail.
Just in case you ever got the two mixed up, this should make things a bit more clear:
IN PRISON... you spend the majority of your time in an 8 x 10 cell.
AT WORK... you spend the majority of your time in a 6 x 8 cubicle.
IN PRISON... you get three meals a day.
AT WORK... you only get a break for one meal and you have to pay for it.
IN PRISON... you get time off for good behavior.
AT WORK... you get rewarded for good behavior with more work.
IN PRISON... the guard locks and unlocks all the doors for you.
AT WORK... you must carry around a security card and open all the doors for yourself.
IN PRISON... you can watch TV and play games.
AT WORK... you get fired for watching TV and playing games.
IN PRISON... you get your own toilet.
AT WORK... you have to share with some idiot who pees on the seat.
IN PRISON...they allow your family and friends to visit.
AT WORK... you can't even speak to your family.
IN PRISON... all expenses are paid by the taxpayers with no work required.
AT WORK... you get to pay all the expenses to go to work and then they deduct taxes from your salary to pay for prisoners.
IN PRISON... you spend most of your life looking through bars from inside wanting to get out.
AT WORK... you spend most of your time wanting to get out and go inside bars.
IN PRISON... you must deal with sadistic wardens.
AT WORK... they are called managers.
Book of the week
Today was a day designated by the TUC where workers were supposed to show their employers the value of unpaid overtime by leaving early.
Any way todays e-mail answer to the work weekend concept was courtesy of a chain e-mail.
Just in case you ever got the two mixed up, this should make things a bit more clear:
IN PRISON... you spend the majority of your time in an 8 x 10 cell.
AT WORK... you spend the majority of your time in a 6 x 8 cubicle.
IN PRISON... you get three meals a day.
AT WORK... you only get a break for one meal and you have to pay for it.
IN PRISON... you get time off for good behavior.
AT WORK... you get rewarded for good behavior with more work.
IN PRISON... the guard locks and unlocks all the doors for you.
AT WORK... you must carry around a security card and open all the doors for yourself.
IN PRISON... you can watch TV and play games.
AT WORK... you get fired for watching TV and playing games.
IN PRISON... you get your own toilet.
AT WORK... you have to share with some idiot who pees on the seat.
IN PRISON...they allow your family and friends to visit.
AT WORK... you can't even speak to your family.
IN PRISON... all expenses are paid by the taxpayers with no work required.
AT WORK... you get to pay all the expenses to go to work and then they deduct taxes from your salary to pay for prisoners.
IN PRISON... you spend most of your life looking through bars from inside wanting to get out.
AT WORK... you spend most of your time wanting to get out and go inside bars.
IN PRISON... you must deal with sadistic wardens.
AT WORK... they are called managers.
Book of the week
Saturday, February 21, 2004
So, I have been asked to work over the weekend...
Anwser: Come and work with me, experience the programming experience...
Answer: Silence
Book of the week
Anwser: Come and work with me, experience the programming experience...
Answer: Silence
Book of the week
Wednesday, January 14, 2004
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
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
}
------------------------------
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
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
}
Wednesday, January 07, 2004
"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!
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!
Monday, January 05, 2004
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...
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...
