|
are you sure?
are you really sure?
are you really really sure?
are you really really really sure?
are you really really really really sure?
are you really really really really really sure?
|
|
|
|
|
Yusuf wrote: are you sure?
are you really sure?
are you really really sure?
are you really really really sure?
are you really really really really sure?
are you really really really really really sure?
Cool!
Cool Cool!
Cool till infinity
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Thats sounds like the coding equivalent of a spice girls song.
I'll tell you when im sure, when im really really sure
So tell me that you're sure, that you're really really sure.
|
|
|
|
|
My favorite part here is the CASE statement.
|
|
|
|
|
It’s absolutely redundant as is the programmer or the DBA who has created this gem.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
"developer redundancy"
Greetings - Jacek
|
|
|
|
|
Well another from the goldmine of coding horrors that is VBA...
Here, two tables have similar structures, and need to be processed similarly (don't ask)...
Naturally, I paraphrase to protect the innocent.
Sub SomeSub()
Dim rs As Recordset
Dim tblname As String
Dim i As Integer
On Error GoTo Err_Handler
tblname = "Table1"
For i = 0 To 1
Set rs = db.OpenRecordset("SELECT * FROM " & tblname & " WHERE ... ")
' Code to process records here
' Including...
NextTable:
tblname = "Table2"
Next i
' Remainder of code
Exit Sub
Err_Handler:
' Code to log error
Resume NextTable ' Note that there's no real error-checking, just logging.
End Sub
(I should mention that code to process records here expands to a couple of hundred lines)
Why, oh why, not define another procedure and call it...
Sub SomeSub()
' Replacement for above
ProcessRecords "Table1"
ProcessRecords "Table2"
End Sub
Sub ProcessRecords(tableName AS String)
' Code to process records here
' When errors occur, can simply return (ideally after some real error-checking)
End Sub
Makes you want to hurl.
|
|
|
|
|
Oh please. Your way might be slightly more elegant, but it is neither more robust, nor faster. You haven't fixed anything, nor really changed anything.
The practical reason for freedom is that freedom seems to be the only condition under which any kind of substantial moral fiber can be developed — we have tried law, compulsion and authoritarianism of various kinds, and the result is nothing to be proud of. ~ Albert Jay Nock
|
|
|
|
|
|
I'd view it as a huge improvement. Take a look at how you'd be hopping around the code on error conditions with what amounts to goto statements (resume NextTable).
The original posters change would be the first thing I'd do as a refactor.
|
|
|
|
|
Jeremy Hutchinson wrote: Take a look at how you'd be hopping around the code on error conditions with what amounts to goto statements (resume NextTable).
VB6 error handling is icky regardless. Depending upon local variable usage, that 'for loop' style may be reasonable. Not great, but given the lack of nice array initializers in VB6 I wouldn't call it horrible. The alternative would be to have a "select case" statement at the start of the loop to set the table name.
|
|
|
|
|
Except that I have to maintain and enhance this code.
Refactoring code for elegance is not wasted time - every future maintainer will appreciate your effort.
|
|
|
|
|
Eeeewww.
Yeah I would definitely change that code. But if you do change it, make sure you change it to use query parameters instead of building SQL from scratch. It's not so bad when the tablename is hard-coded into the method itself but if passed in from outside, it's a huge security hole. (Some future slave might decide to call the method with user-provided input, and it won't be properly escaped)
It's so hard to find good slaves today...
Before .NET 4.0,
object Universe = NULL;
|
|
|
|
|
What i really like the most is the "Err_Handler". So beautiful, so classical, so elegant
|
|
|
|
|
I've been looking at some code today written by a former slave. Now instead of using member variables in methods, dufus decided to pass them all around the shop as arguments to STATIC methods so we get crapola like this:
class DoofusCode {
private int first;
private String second;
public void Method()
{
if (IsFirst(first))
UpdateSecond(out second);
}
private static bool IsFirst(int first)
{
return answer;
}
private static void IsFirst(out String second)
{
second = "Second";
}
}
Go Optimisers! Go!
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
if the class members aren't static and the methods are, what do you want your slaves to do? anyway, if you don't educate and whip them enough, it is your problem, you're the master after all.
|
|
|
|
|
There is no need for the methods to be static. Numpty made them static to get rid of the build warnings that the methods didn't reference any member variables.
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
Nagy Vilmos wrote: the build warnings that the methods didn't reference any member variables
Interesting. While I always build my C# apps at warning level 4, I've never seen such a warning, and I seem unable to get one on purpose either.
|
|
|
|
|
I would guess the warning comes from some 3rd party tool like Resharper.
|
|
|
|
|
|
explicitly making a method static can be useful as it turns every access to an instance member into an error.
|
|
|
|
|
And reentrant code is happy code.
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
|
|
|
|
|
Well those tools are normally intelligent enough to generate such warnings only for private methods. I can't think of a situation where a private method which doesn't access any member variables shouldn't be static (except temporarily while developing). And even if there are, you can still ignore it .
|
|
|
|
|
Funny, I have the opposite viewpoint. I regard static members of any type - including such methods - as a code smell. If a method has requires no access to an instance's state, is it really a method at all, are we really doing object-oriented programming here?
Gilad Bracha's Room 101[^] has some excellent posts on the problems of static. Particular, look for "Constructors considered harmful" (they're a form of static method), and "Cutting out static".
|
|
|
|
|
Rob Grainger wrote: If a method has requires no access to an instance's state, is it really a method at all, are we really doing object-oriented programming here?
Ah, ladies and gentlemen, we have a purist in our midst!
One of the things OOP enthusiasts forget is that one of the purposes of classes (as opposed to objects) is to organize behavior. A method that does not reference an instance state might still be perfectly appropriate if it implements a behavior relevant to the class. The method might implement an operation or perform a calculation for objects of the class type that depends solely on arguments to the operation.
Software Zen: delete this;
|
|
|
|