When to check for null ?
-
Another project from our "star" developer who is apparently beyond contempt in every way. I was given this website (an ASP.Net Webforms project written in VB10) to add some additional metrics. To my horror I found that even though written very recently (within the last 2-3 years) and then updated to use a new Linq-to-Entities data source, there was no regard for architecture, and all of the data access code was written directly in the code behind of the aspx pages. That's not even the real horror. I was getting (seemingly) random errors while trying to run it/understand it, and found that through-out all of the loads of Linq statements that all of the nullable types (e.g. Integer?, Double?, DateTime?, etc.) were being treated as if they were not nullable at all! Here is an example to help you understand (table/field names changed slightly to protect the guilty):
Dim partTransactionTypeThingsQuery As IQueryable(Of SomeTransactionRelatedItem) = \_ From t In baseQuery Join tji In dataContext.OtherTransactionItems \_ On tji.SomeTransactionID Equals t.ID Where (t.LastUpdatedDate >= startDate \_ And t.LastUpdatedDate < endDate) \_ And (tji.Type = "Part") \_ And (tji.TotalDue <> 0) Select tjiLastUpdatedDate is a Nullable(Of Date) and TotalDue is a Nullable(Of Double) and when it translates to SQL it will work just fine.. The problems come about when the context switches from Linq-To-Entities to Linq-To-Objects (I have to watch closely for a .ToArray() or .ToList() or anything else that executes the SQL and fetches results) and much of the aggregation is doing exactly that. I don't even know how many of these problems there are... Anyways, thanks for letting me rant a bit. Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
-
Another project from our "star" developer who is apparently beyond contempt in every way. I was given this website (an ASP.Net Webforms project written in VB10) to add some additional metrics. To my horror I found that even though written very recently (within the last 2-3 years) and then updated to use a new Linq-to-Entities data source, there was no regard for architecture, and all of the data access code was written directly in the code behind of the aspx pages. That's not even the real horror. I was getting (seemingly) random errors while trying to run it/understand it, and found that through-out all of the loads of Linq statements that all of the nullable types (e.g. Integer?, Double?, DateTime?, etc.) were being treated as if they were not nullable at all! Here is an example to help you understand (table/field names changed slightly to protect the guilty):
Dim partTransactionTypeThingsQuery As IQueryable(Of SomeTransactionRelatedItem) = \_ From t In baseQuery Join tji In dataContext.OtherTransactionItems \_ On tji.SomeTransactionID Equals t.ID Where (t.LastUpdatedDate >= startDate \_ And t.LastUpdatedDate < endDate) \_ And (tji.Type = "Part") \_ And (tji.TotalDue <> 0) Select tjiLastUpdatedDate is a Nullable(Of Date) and TotalDue is a Nullable(Of Double) and when it translates to SQL it will work just fine.. The problems come about when the context switches from Linq-To-Entities to Linq-To-Objects (I have to watch closely for a .ToArray() or .ToList() or anything else that executes the SQL and fetches results) and much of the aggregation is doing exactly that. I don't even know how many of these problems there are... Anyways, thanks for letting me rant a bit. Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
X| And to those who will start the VB vs. C# debate, it is not VB that it the problem. The Problem exists between the chair and the keyboard. (AKA, PEBKAC)
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions. Dave Barry Read more at [BrainyQuote](http://www.brainyquote.com/quotes/topics topic_technology.html#yAfSEbrfumitrteO.99)[^]
-
X| And to those who will start the VB vs. C# debate, it is not VB that it the problem. The Problem exists between the chair and the keyboard. (AKA, PEBKAC)
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions. Dave Barry Read more at [BrainyQuote](http://www.brainyquote.com/quotes/topics topic_technology.html#yAfSEbrfumitrteO.99)[^]
PEBKAC ! I had forgotten about that one, thanks for reminding me. Yes, I would say that is usually a problem with computers. Also, thanks for reading my rant it makes me feel like at least someone listened. As for the C# vs. VB debates, I don't really mind. It really gets so funny at times (people will argue the silliest things based on ideas that aren't even true). There is no problem with VB.Net especially for those of us who code using 'Option Strict On' (I'm really biased towards static typing). I find VB preferable because of the way you can easily tell where each block begins and ends. Doing so with this is hard for me: {{{{{{{{{{}}}}}}}}}} :confused:
-
X| And to those who will start the VB vs. C# debate, it is not VB that it the problem. The Problem exists between the chair and the keyboard. (AKA, PEBKAC)
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions. Dave Barry Read more at [BrainyQuote](http://www.brainyquote.com/quotes/topics topic_technology.html#yAfSEbrfumitrteO.99)[^]
You are wrong. VB is the problem. It was always sold as sooooo easy to learn and use and then remained the safe harbor for all the horror coders they had picked up. A kind of Jurassic Park for coders. Give a user a program and he can work for a day. Show the user how to program and you have work for the rest of your life.
At least artificial intelligence already is superior to natural stupidity
-
You are wrong. VB is the problem. It was always sold as sooooo easy to learn and use and then remained the safe harbor for all the horror coders they had picked up. A kind of Jurassic Park for coders. Give a user a program and he can work for a day. Show the user how to program and you have work for the rest of your life.
At least artificial intelligence already is superior to natural stupidity
CDP1802 wrote:
Give a user a program and he can work for a day. Show the user how to program and you have work for the rest of your life.
Love that one :)
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood 'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
-
CDP1802 wrote:
Give a user a program and he can work for a day. Show the user how to program and you have work for the rest of your life.
Love that one :)
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood 'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
But please don't get me wrong. I have met people who taught themselves and also were very capable of logical thinking. Once a mailman (who only had some experience on a C64) told me about the bugs in a Win32 program, where to look in the code and how to fix them. And then there is that great mass of users who think they know everything...
At least artificial intelligence already is superior to natural stupidity
-
But please don't get me wrong. I have met people who taught themselves and also were very capable of logical thinking. Once a mailman (who only had some experience on a C64) told me about the bugs in a Win32 program, where to look in the code and how to fix them. And then there is that great mass of users who think they know everything...
At least artificial intelligence already is superior to natural stupidity
Yup, I've got some mixed experiences too: on the one hand self-taught guy who did great complicated stuff, like expert systems, AI, etc... and on the other hand supposedly 'educated' engineers who couldn't tell a variable from an instruction. And users, ah users, ...
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood 'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
-
PEBKAC ! I had forgotten about that one, thanks for reminding me. Yes, I would say that is usually a problem with computers. Also, thanks for reading my rant it makes me feel like at least someone listened. As for the C# vs. VB debates, I don't really mind. It really gets so funny at times (people will argue the silliest things based on ideas that aren't even true). There is no problem with VB.Net especially for those of us who code using 'Option Strict On' (I'm really biased towards static typing). I find VB preferable because of the way you can easily tell where each block begins and ends. Doing so with this is hard for me: {{{{{{{{{{}}}}}}}}}} :confused:
I always have Option Strict On, and a lot of VB projects I download from different sites won't compile with it on, so I modify them to compile.
Bill Gates is a very rich man today... and do you want to know why? The answer is one word: versions. Dave Barry Read more at [BrainyQuote](http://www.brainyquote.com/quotes/topics topic_technology.html#yAfSEbrfumitrteO.99)[^]
-
You are wrong. VB is the problem. It was always sold as sooooo easy to learn and use and then remained the safe harbor for all the horror coders they had picked up. A kind of Jurassic Park for coders. Give a user a program and he can work for a day. Show the user how to program and you have work for the rest of your life.
At least artificial intelligence already is superior to natural stupidity
Quote:
You are wrong. VB is the problem.
I'm afraid not. Go ahead and open your mouth and insert your shoe. In this case it is a combination of ignorance and arrogance that is the problem (something that you also seem to be displaying by this comment). Since you know so much about the culture of my workplace, why don't you expound upon that?
-
You are wrong. VB is the problem. It was always sold as sooooo easy to learn and use and then remained the safe harbor for all the horror coders they had picked up. A kind of Jurassic Park for coders. Give a user a program and he can work for a day. Show the user how to program and you have work for the rest of your life.
At least artificial intelligence already is superior to natural stupidity
CDP1802 wrote:
You are wrong. VB PHP is the problem
FTFY :laugh: On a more serious note, I don't think any language is the problem. The problem is the people using them...
-
Another project from our "star" developer who is apparently beyond contempt in every way. I was given this website (an ASP.Net Webforms project written in VB10) to add some additional metrics. To my horror I found that even though written very recently (within the last 2-3 years) and then updated to use a new Linq-to-Entities data source, there was no regard for architecture, and all of the data access code was written directly in the code behind of the aspx pages. That's not even the real horror. I was getting (seemingly) random errors while trying to run it/understand it, and found that through-out all of the loads of Linq statements that all of the nullable types (e.g. Integer?, Double?, DateTime?, etc.) were being treated as if they were not nullable at all! Here is an example to help you understand (table/field names changed slightly to protect the guilty):
Dim partTransactionTypeThingsQuery As IQueryable(Of SomeTransactionRelatedItem) = \_ From t In baseQuery Join tji In dataContext.OtherTransactionItems \_ On tji.SomeTransactionID Equals t.ID Where (t.LastUpdatedDate >= startDate \_ And t.LastUpdatedDate < endDate) \_ And (tji.Type = "Part") \_ And (tji.TotalDue <> 0) Select tjiLastUpdatedDate is a Nullable(Of Date) and TotalDue is a Nullable(Of Double) and when it translates to SQL it will work just fine.. The problems come about when the context switches from Linq-To-Entities to Linq-To-Objects (I have to watch closely for a .ToArray() or .ToList() or anything else that executes the SQL and fetches results) and much of the aggregation is doing exactly that. I don't even know how many of these problems there are... Anyways, thanks for letting me rant a bit. Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
Just fix your stored procedures so they don't return nulls.
-
Just fix your stored procedures so they don't return nulls.
That's a great idea. Now if only I had the access to do that...
-
CDP1802 wrote:
You are wrong. VB PHP is the problem
FTFY :laugh: On a more serious note, I don't think any language is the problem. The problem is the people using them...
PHP? That's Triassic Park! :) Every language may have a share of bad coders, but some have been advertised to them as being especially 'easy to learn'. They were called and they came. The languages may have evolved over time, but many of the coders have not.
At least artificial intelligence already is superior to natural stupidity
-
That's a great idea. Now if only I had the access to do that...
Sasha Laurel wrote:
That's a great idea. Now if only I had the access to do that...
In this case, yes, suicide is a very tempting alternative. Homicide, on the other hand, mmm... ;) ;)...sweet I've found a nice way to punish the original coders when I come across stuff like this. Ask them what they intended to do in that portion(s) of the code, and WHY they did it so. It's not offensive, and it's perfectly justifiable. Now, one of two things may happen: - You, made to look like a fool if they can come up with a good explanation why they did what they did (which is ok with me, 'cause at least I can understand, and I don't mind admitting sometimes I'm just plain dumb), or - The 'WTF-did-I-do-here-can't-remember-can't-justify look on their faces, which is purely priceless (it may not help in untangling that code, but my ego will feel a really nice tickle-tingle) Now, in your specific case, I have no idea what would help, short of modifying the whole codebase :( :(
-
Another project from our "star" developer who is apparently beyond contempt in every way. I was given this website (an ASP.Net Webforms project written in VB10) to add some additional metrics. To my horror I found that even though written very recently (within the last 2-3 years) and then updated to use a new Linq-to-Entities data source, there was no regard for architecture, and all of the data access code was written directly in the code behind of the aspx pages. That's not even the real horror. I was getting (seemingly) random errors while trying to run it/understand it, and found that through-out all of the loads of Linq statements that all of the nullable types (e.g. Integer?, Double?, DateTime?, etc.) were being treated as if they were not nullable at all! Here is an example to help you understand (table/field names changed slightly to protect the guilty):
Dim partTransactionTypeThingsQuery As IQueryable(Of SomeTransactionRelatedItem) = \_ From t In baseQuery Join tji In dataContext.OtherTransactionItems \_ On tji.SomeTransactionID Equals t.ID Where (t.LastUpdatedDate >= startDate \_ And t.LastUpdatedDate < endDate) \_ And (tji.Type = "Part") \_ And (tji.TotalDue <> 0) Select tjiLastUpdatedDate is a Nullable(Of Date) and TotalDue is a Nullable(Of Double) and when it translates to SQL it will work just fine.. The problems come about when the context switches from Linq-To-Entities to Linq-To-Objects (I have to watch closely for a .ToArray() or .ToList() or anything else that executes the SQL and fetches results) and much of the aggregation is doing exactly that. I don't even know how many of these problems there are... Anyways, thanks for letting me rant a bit. Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
-
This is probably actually Microsoft's fault: a Linq query should work the same for a query against the database, or a query against an in-memory object that was created by evaluating a Linq query on that same database.
Interesting idea! I wonder what the implications would be for an IQueryable provider. Oh well, I'm mostly just wanting to piss and moan at the moment.. ;)
-
Another project from our "star" developer who is apparently beyond contempt in every way. I was given this website (an ASP.Net Webforms project written in VB10) to add some additional metrics. To my horror I found that even though written very recently (within the last 2-3 years) and then updated to use a new Linq-to-Entities data source, there was no regard for architecture, and all of the data access code was written directly in the code behind of the aspx pages. That's not even the real horror. I was getting (seemingly) random errors while trying to run it/understand it, and found that through-out all of the loads of Linq statements that all of the nullable types (e.g. Integer?, Double?, DateTime?, etc.) were being treated as if they were not nullable at all! Here is an example to help you understand (table/field names changed slightly to protect the guilty):
Dim partTransactionTypeThingsQuery As IQueryable(Of SomeTransactionRelatedItem) = \_ From t In baseQuery Join tji In dataContext.OtherTransactionItems \_ On tji.SomeTransactionID Equals t.ID Where (t.LastUpdatedDate >= startDate \_ And t.LastUpdatedDate < endDate) \_ And (tji.Type = "Part") \_ And (tji.TotalDue <> 0) Select tjiLastUpdatedDate is a Nullable(Of Date) and TotalDue is a Nullable(Of Double) and when it translates to SQL it will work just fine.. The problems come about when the context switches from Linq-To-Entities to Linq-To-Objects (I have to watch closely for a .ToArray() or .ToList() or anything else that executes the SQL and fetches results) and much of the aggregation is doing exactly that. I don't even know how many of these problems there are... Anyways, thanks for letting me rant a bit. Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
Sasha Laurel wrote:
Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
No, just consider it job security :rolleyes:
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Sasha Laurel wrote:
Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
No, just consider it job security :rolleyes:
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
Job Security! Just the positive spin that I needed. Thank you sir!
-
Job Security! Just the positive spin that I needed. Thank you sir!
Sasha, you might have to keep reminding higher up management that it will take time to eventually get it all taken care of if they start playing whiny games about it taking time.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Another project from our "star" developer who is apparently beyond contempt in every way. I was given this website (an ASP.Net Webforms project written in VB10) to add some additional metrics. To my horror I found that even though written very recently (within the last 2-3 years) and then updated to use a new Linq-to-Entities data source, there was no regard for architecture, and all of the data access code was written directly in the code behind of the aspx pages. That's not even the real horror. I was getting (seemingly) random errors while trying to run it/understand it, and found that through-out all of the loads of Linq statements that all of the nullable types (e.g. Integer?, Double?, DateTime?, etc.) were being treated as if they were not nullable at all! Here is an example to help you understand (table/field names changed slightly to protect the guilty):
Dim partTransactionTypeThingsQuery As IQueryable(Of SomeTransactionRelatedItem) = \_ From t In baseQuery Join tji In dataContext.OtherTransactionItems \_ On tji.SomeTransactionID Equals t.ID Where (t.LastUpdatedDate >= startDate \_ And t.LastUpdatedDate < endDate) \_ And (tji.Type = "Part") \_ And (tji.TotalDue <> 0) Select tjiLastUpdatedDate is a Nullable(Of Date) and TotalDue is a Nullable(Of Double) and when it translates to SQL it will work just fine.. The problems come about when the context switches from Linq-To-Entities to Linq-To-Objects (I have to watch closely for a .ToArray() or .ToList() or anything else that executes the SQL and fetches results) and much of the aggregation is doing exactly that. I don't even know how many of these problems there are... Anyways, thanks for letting me rant a bit. Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
Sasha Laurel wrote:
Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?
Depends on what you call viable. If you want to get out of this problem as quickly as possible, no matter the cost, then yes. Personally, I'd say the cost is too high to consider it. :-D (That's disregarding the subsequent funeral costs you'll impose on someone else.) PS your quote had really weird markups that I haven't seen code project do before. I stripped the verbose "span" markup surrounding every lower-case "i" in your note.