We need more keys!
-
Take a peek at some VB. That should at least replace the horror with one that is at least expected.
I wasn't, now I am, then I won't be anymore.
As a VB programmer I see my share of VB... Seen many horrors as well (VB6 and even pre-VB4 practices in .NET) ;) I have no doubt there is legacy C# code that is as bad as legacy VB code or even worse though. In the end code is as good as the programmer writes it, independent of the language ;)
It's an OO world.
public class Naerling : Lazy<Person>{}
-
As a VB programmer I see my share of VB... Seen many horrors as well (VB6 and even pre-VB4 practices in .NET) ;) I have no doubt there is legacy C# code that is as bad as legacy VB code or even worse though. In the end code is as good as the programmer writes it, independent of the language ;)
It's an OO world.
public class Naerling : Lazy<Person>{}
touche.... There is definitely some horrible C# code out there. For that matter, horrible code exists in every language. I equate that to people of any given language who have no understanding of grammar, syntax or punctuation. I have a lot of vb and vb.net systems that I work with daily as well. I tend to find that vb lends itself to being ugly by nature which is why I prefer C# and C++ to vb.
I wasn't, now I am, then I won't be anymore.
-
touche.... There is definitely some horrible C# code out there. For that matter, horrible code exists in every language. I equate that to people of any given language who have no understanding of grammar, syntax or punctuation. I have a lot of vb and vb.net systems that I work with daily as well. I tend to find that vb lends itself to being ugly by nature which is why I prefer C# and C++ to vb.
I wasn't, now I am, then I won't be anymore.
When programming VB just make sure to uncheck the VisualBasic Namespace reference and put Option Strict on. That's the first step in the right direction! :thumbsup:
It's an OO world.
public class Naerling : Lazy<Person>{}
-
As a VB programmer I see my share of VB... Seen many horrors as well (VB6 and even pre-VB4 practices in .NET) ;) I have no doubt there is legacy C# code that is as bad as legacy VB code or even worse though. In the end code is as good as the programmer writes it, independent of the language ;)
It's an OO world.
public class Naerling : Lazy<Person>{}
-
I just came across an SQL table with 10 columns of which 7 formed the Primary Key... :wtf: No further indexing/unique contraints applied. No Foreign Key Relationships (at all) where they were very obviously necessary. Redundant information that was already stored in the table that this table should have related too (and almost inevitably were part of the PK)... This was just a small table that held some additional information on invoices (the table which it should have related to) :sigh: Appearently this is how the table was described in the specifications of the customer... Well, I've got news for them! We don't work that way! A shame this table came to be at all... :(( What has been seen can't be unseen. I will undoubtedly have some nightmares about this :( Edit: To give a small indication of how bad things really are, one of the PK columns was a varchar(50) X|
It's an OO world.
public class Naerling : Lazy<Person>{}
Any chance at getting to normalize the table? If met with resistance from the customer about normalizing, sell the idea of performance benefits.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
-
True, but neither VB nor C# prevents you from writing code as it should be :) I'm a VB programmer most of the time, but you don't see me using OnErrorResumeNext or GoTo. And an empty try catch block is just as easy to write in C# as in VB.
It's an OO world.
public class Naerling : Lazy<Person>{}
-
Any chance at getting to normalize the table? If met with resistance from the customer about normalizing, sell the idea of performance benefits.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
Yeah, it's going to be okay. Luckily. I found another table like that today (it's all the same schema, so we know where it's wrong). Seriously, no table in the schema has any FK's. A few tables are like the one I described. And this is a vital part of our system! X|
It's an OO world.
public class Naerling : Lazy<Person>{}
-
True, but neither VB nor C# prevents you from writing code as it should be :) I'm a VB programmer most of the time, but you don't see me using OnErrorResumeNext or GoTo. And an empty try catch block is just as easy to write in C# as in VB.
It's an OO world.
public class Naerling : Lazy<Person>{}
Naerling wrote:
but you don't see me using OnErrorResumeNext or GoTo
If you did and I found out, you's get a virtual slap through the monitor from me... :)
I wasn't, now I am, then I won't be anymore.
-
I just came across an SQL table with 10 columns of which 7 formed the Primary Key... :wtf: No further indexing/unique contraints applied. No Foreign Key Relationships (at all) where they were very obviously necessary. Redundant information that was already stored in the table that this table should have related too (and almost inevitably were part of the PK)... This was just a small table that held some additional information on invoices (the table which it should have related to) :sigh: Appearently this is how the table was described in the specifications of the customer... Well, I've got news for them! We don't work that way! A shame this table came to be at all... :(( What has been seen can't be unseen. I will undoubtedly have some nightmares about this :( Edit: To give a small indication of how bad things really are, one of the PK columns was a varchar(50) X|
It's an OO world.
public class Naerling : Lazy<Person>{}
You're right, it's not how we do things here, following procedure would require at least 10 primary key column! :P Remember, it's more important to follow procedure than being actually productive! ;)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Take a peek at some VB. That should at least replace the horror with one that is at least expected.
I wasn't, now I am, then I won't be anymore.
A truly talented programmer can mess things up in any language, not only VB :-D
-
Yeah, it's going to be okay. Luckily. I found another table like that today (it's all the same schema, so we know where it's wrong). Seriously, no table in the schema has any FK's. A few tables are like the one I described. And this is a vital part of our system! X|
It's an OO world.
public class Naerling : Lazy<Person>{}
I have once worked with a customer database that had tables with 40 columns, no FK and PK of type varchar(50). Heck the Names column was primary key, when I asked the client what'll happen if another guy joins the Org with same name as his, he was shell shocked. :laugh:
