Chubertdev's snippet thread
-
With Ctrl1
.Property = Value
End With
Ctrl2.Property1 = Value1
Ctrl2.Property2 = Value2
Ctrl2.Property3 = Value3
Ctrl2.Property4 = Value4Are you sure you aren't being trolled with this one?
-
Holy hell.
else if (res is SqlException) { SqlException exp = (SqlException)res; Logger.Log(exp.Message); }</blockquote>
If you don't do this, the logger might eat your variable. THEN WHAT WOULD YOU DO, HUH?
-
Private Function Logon(ByVal bLogon As Boolean) As Boolean
It's not hard to figure out what happens if you pass False to this function.
Please tell me the answer is anything but "it logs you off."
-
Please tell me the answer is anything but "it logs you off."
That would be too much. None of this code is wrong, it's just bad. Like the DataSet/HashTable above, it works, but it looks like someone just hacked at it until they got it to work.
-
Find all "= Nothing\n", Regular expressions, Subfolders, Find Results 1, "Entire Solution", "*.vb" Matching lines: 267 Matching files: 21 Total files searched: 155
-
oh dear. that can't be good.....
-
It's not bad. It's just pointless.
If bConditional Then Dim strText As String = txtField1.Text DoStuff(strText) strText = Nothing End If
-
defensive coding gone wrong?
-
That's not defensive, that's just terrible in general.
-
like i said, gone wrong.
-
more or less. this is the app with 22 anti-patterns (that I've bothered to document). this is one of them.
-
It's not bad. It's just pointless.
If bConditional Then
Dim strText As String = txtField1.Text
DoStuff(strText)
strText = Nothing
End IfSomeone tried to track down the origin of that anti-mini-pattern a few years ago. Best guess it "outdated advice about ADO needlessly generalized."
I've seen it in some of our code, but that code is ancient and I remove it as I find it.
-
Someone tried to track down the origin of that anti-mini-pattern a few years ago. Best guess it "outdated advice about ADO needlessly generalized."
The only reason i can think of doing the first part is for asynchronous multistep processing of the form field value. you want to catch the value that triggered the processing so if the user changes it while you are processing it you have the old value to finish processing..
ad even then that's not the quoted case because it's
- not async processing
- only one step so who the [copulation] cares? unless VB is one of those [excrement] languages that have mutable strings? (mutable strings are EVIL!)
setting it to null at the end though? useless AFAICT
-
you want to catch the value that triggered the processing
I'll be making an assumption that the function called takes the param ByVal, which means it's already working on a copy and not the original string. If it isn't, then assigning the string to another variable to avoid it getting modified is an option, but setting it to Nothing after is pointless.
unless .NET is one of those [excrement] languages that have mutable strings? (mutable strings are EVIL!)
FTFY, and yes and no. String is immutable, StringBuilder is not (but it's worked with fairly differently).
-
I'll be making an assumption that the function called takes the param ByVal, which means it's already working on a copy and not the original string. If it isn't, then assigning the string to another variable to avoid it getting modified is an option,
I rather meant sequential async calls, where the valuie could change between calling the first one and calling the second.
FTFY, and yes and no. String is immutable, StringBuilder is not (but it's worked with fairly differently).
I figured as much (i do C# and know it's a common CLR) but wasn't positive because... well it's VB.
-
I rather meant sequential async calls
Yes, that'd be a concern if the DoStuff method takes the
String
ByRef and would be built to allow async calls.Given the context otherwise though, I doubt that's the case. I believe this is the .NET 1 code being ported, and by other examples, it's ASP.NET, not WinForms. I honestly don't know how well .NET 1 supported async/threading in WinForms.
well it's VB
Which isn't a great mindset, since VB.NET is closer to C# than it is classic VB in most ways except syntax.
-
I honestly don't know how well .NET 1 supported async/threading in WinForms.
It didn't. i mean you could do it with threads, maybe, but why?
Which isn't a great mindset, since VB.NET is closer to C# than it is classic VB in most ways except syntax.
i have been thoroughly chastised.
-
but why?
Because threads are the future.Seriously, though, it's nice to have a WinForm application that is still responsive if it's "doing something" without having to write it like you did in Classic VB (i.e. DoEvents sprinkled everywhere).
As for why I said that, it's a slight curiosity, since I (thankfully) went straight to .NET 2 when I started working with the framework (though I've since had to do ASP.NET 1.1 stuff, which isn't awful).
i have been thoroughly chastised.
Don't feel too bad. Good chance that tomorrow I'll be pulled out of the .NET world and mucking about in an Access/VBA pit to add features and fix things when the system should've been dropped for something newer and better many years ago.
-
Because threads are the future.
in .NET1 or even pre .NET VB?
pass. if you want em to do async i'mma need at least .Nrt 2.5 and for preference .Net 4.5
-
Someone tried to track down the origin of that anti-mini-pattern a few years ago. Best guess it "outdated advice about ADO needlessly generalized."
That's a pattern from Classic VB. Everything was reference counted and self-destructed when the reference count hit zero. In theory, the VB engine automaticallyNothing
ed everything that went out of scope. In practice, ... well, let's just say there's a reason the patterned existed.Makes no god damn sense to still stick around though; the last time that was useful was 2001.
ETA: .NET 1.0 did support threading by hand with the Framework, but the BackgroundWorker component that made it easy for WinForms didn't come out until .NET 1.1, the
Task
classes didn't come out until .NET 4, and the magicalasync
goo won't come out for VB until .NET Roslyn hits. Classic VB, though,DoEvents()
or die.
Filed under: we need a new tag cloud to attack, COM/OLE lives!
-
The only reason i can think of doing the first part is for asynchronous multistep processing of the form field
If I can remember this right--and I have no guarantee I do--the person who did the delving thought there was a bug in an old version of ADO that didn't release resources properly if you didn't set your recordsets, connections, and so on to nothing. The theory is that the technique became cargo culted into other contexts: "oh, you have to set the object to nothing when you're done with it" and people forget the "to release resources" part, and even if they don't, they don't think about how most objects don't have the kind of resources--in this case, database connections--that need to be explicitly freed.
-
Seriously, though, it's nice to have a WinForm application that is still responsive if it's "doing something" without having to write it like you did in Classic VB (i.e. DoEvents sprinkled everywhere).
Which, I vaguely remember, is actually Doing It WrongTM.
-
Yup, but in classic VB, that was really the only option.
I don't miss those days.
-
-
There is absolutely no way that the original author put in a tenth of that amount of thought into this code.
-
they don't think about how most objects don't have the kind of resources--in this case, database connections--that need to be explicitly freed.
Using conn As New SqlConnection(strConnString) ... End Using
-
You think someone who uses "set myobject = nothing" is going to know about using?
-
Hence my comment before that one.
-
Can't remember if I posted this, but there are a number of WTFs in here. Although one is just style.
(csp is a
SqlParameterCollection
)For Each sp As SqlParameter In csp If sp.Direction = ParameterDirection.Output Or sp.Direction = ParameterDirection.InputOutput _ Then If Not IsDBNull(sp.Value) Then iTestOrderID = sp.Value End If End If Next
-
Just set the app so that implicit conversions are errors. I got an error with this code.
If bRequireCondition = False Then Else ... End If
So not only does it have an empty
If
clause, but it turns out that bRequireCondition is an integer.
-
If Method(Arguments) Then ... Else Throw New Exception("blah blah blah") End If
Because throwing the exception from inside the method would be too smart.
-
People not familiar with .NET (including the original author) may not get this one:
sValue = FormatDateTime(sValue, DateFormat.ShortDate) & " " & _ FormatDateTime(sValue, DateFormat.ShortTime)
-
Oddly enough, a Q'n'D test resulted in this:
that's your[1] code and a DateFormat.GeneralDate.
Either that or I whoooshed.
[1] you know what I meant. I don't want you to think I was trying to insult you by implying you wrote that.
-
I'd just use
CDate(sValue).ToString("format")
, withformat
being what matches the ShortDate/ShortTime combo.
-
Sigh.
If .Item("equals").ToString.Trim = "NULL" Then
-
If .Item("equals").ToString.Trim = "NULL" Then
This seems like it's not enterprisey enough. I recommend JSON.
-
One thing that I hate is that VB is very inconsistent with parens. I'd expect a compiler error with
.ToString
or.Trim
instead of.ToString()
or.Trim()
.
-
-
One thing that I hate is that VB is very inconsistent with parens.
Isn't the rule that parameterless functions don't need the parens?
-
Isn't the rule that parameterless functions don't need the parens?
Both work the same for parameterless functions, but that's what I don't like. In something like JS where
Method()
is a reference versusMethod
being a pointer, I just find it inconsistent.
-
Fair enough. I just chalk it up to the vagaries of the language. You could try to institute a corporate rule that people not use 'em for the sake of readability.
-
Fair enough. I just chalk it up to the vagaries of the language. You could try to institute a corporate rule that people not use 'em for the sake of readability.
Usage vs. what's allowed, that's a bit different. I don't mind how people use them, it's just that the language even allows it that blows my mind. If you start learning .NET in VB like I did, then transition to C#, it makes the move that much harder.
-
That's a long-time idiom in VB. I agree it's a bad one, but it is what it is, I guess. If MS weren't trying for some semblance of backwards compatibility I bet they would've gotten rid of it.
But in a world where Befunge is a think, this isn't much of a WTF, it's more like a WTFirst base.
-
There's something much worse about Functions in the VBs:
Function doStuff(num as Integer) Dim result as Integer result = num + 1 doStuff = result End Function
The dumbest way to write return ever.
-
I can only assume that this is from refactoring while only thinking about one line at a time:
Dim li As New ListItem li = New ListItem
-
There's something much worse about Functions in the VBs:
Function doStuff(num as Integer) Dim result as Integer result = num + 1 doStuff = result End Function
The dumbest way to write return ever.
Yeah, I hate that design.
-
This post is deleted!
-
If MS weren't trying for some semblance of backwards compatibility I bet they would've gotten rid of it.
Meh. If they were trying, you'd be able to write QBasic in this.
Filed under: 10 GOSUB 3000
-
I'm tempted to post this
DownloadtoExcel(ByVal dtExcel As DataTable)
method that I'm looking at right now. It's..........interesting.
-
The dumbest way to write return ever.
I hate it too, but it's a byproduct of "compatibility".
Personally, I purge it everywhere I can when I find it, even if VB is being helpful and effectively giving you a "free" variable (named the same as the function) and returning it at the end for you instead of you having to do it manually.