It's a jungle in there
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
-
As a consultant I share your pain.
GibbleCH wrote:
Tons of duplicated code. Crazy amounts of dead code (~30-50%)
sounds like it would be quicker to re-write
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
I see the opposite way to often too...
Private Sub DoSomething
Try
' Lots of badly written code inspired by VB6 and earlier here.
Catch ex As ExceptionEnd Try
A Try Catch block with no code does no harm, this however... :sigh: Perhaps the empty Catch is also VB6 inspired... OnErrorResumeNext :(
It's an OO world.
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
I think the guy created a function body to copy for other functions. That would save him writing the exception handling block over and over again when a new function is added. No coding horror, though it might look like one at first view.
-
I think the guy created a function body to copy for other functions. That would save him writing the exception handling block over and over again when a new function is added. No coding horror, though it might look like one at first view.
-
I think the guy created a function body to copy for other functions. That would save him writing the exception handling block over and over again when a new function is added. No coding horror, though it might look like one at first view.
try [enter] or try[tab][tab] even if you have already written the code- select code and [ctrl][k][s] try [enter] -
I see the opposite way to often too...
Private Sub DoSomething
Try
' Lots of badly written code inspired by VB6 and earlier here.
Catch ex As ExceptionEnd Try
A Try Catch block with no code does no harm, this however... :sigh: Perhaps the empty Catch is also VB6 inspired... OnErrorResumeNext :(
It's an OO world.
Naerling wrote:
Perhaps the empty Catch is also VB6 inspired... OnErrorResumeNext
Is it just me or everytime someone talks about bad code, "VB" shows up? :sigh:
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
I see the opposite way to often too...
Private Sub DoSomething
Try
' Lots of badly written code inspired by VB6 and earlier here.
Catch ex As ExceptionEnd Try
A Try Catch block with no code does no harm, this however... :sigh: Perhaps the empty Catch is also VB6 inspired... OnErrorResumeNext :(
It's an OO world.
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
-
Naerling wrote:
Perhaps the empty Catch is also VB6 inspired... OnErrorResumeNext
Is it just me or everytime someone talks about bad code, "VB" shows up? :sigh:
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
I blame VB 1, 2 and 3. I was a toddler at that time so I wouldn't know, but this is what I heard. VB became object oriented at version 4, but to be backwards compatible MS had to support the non-object oriented style. As a result many VB programmers kept on programming like they always did and still do so today. Why not C#? Because the first C# came at around the same time as VB4 and was object oriented right from the start. On a side note, try to call any PUBLIC member of a Form in VB without having an instance of the Form. It will work, you can call them as if they were Shared (static). I recently found out and was shocked, backwards compatibility with VB1... X| Anyway, I don't really blame VB, I blame the programmers who were not willing to learn object orientism right after VB3 :sigh: Does that sound about right or am I really way off here?
It's an OO world.
-
There was tons of that in there too. Along with lots of catch blocks that broke the call stack by throwing a new, useless error message.
Or my favourite:
Try
' (Lots of) code here.
Catch ex As Exception
LogError(0, ex.Message, "SomeClass.SomeMethod")
End TryYes, we did not pass the Exception Object to the LogError Method, we provided some parameters as Strings. I still don't know what the first parameter is. It is always 0... "SomeClass.SomeMethod" is not fetched from the Exception Object, but passed as a fixed String. It gets worse, because this piece of code is copied in EVERY Try Catch block (except the empty ones of course). See how copying "SomeClass.SomeMethod" does not work for "SomeClass.OtherMethod"? :) So our logging is often not very reliable. And even if it is (it is not ALL bad) it usually does not say very much because we don't log stacktraces etc. A log that says "Reference not set to an instance of an Object" in a Method with some 100 lines of code is really not very helpful :) Next to that there is a Try Catch block in almost EVERY Method, but NEVER a ReThrow or a MessageBox.Show to the user. What a way to handle Exceptions! :thumbsup: It annoyed me so much I decided to write an article about it :)
It's an OO world.
-
I think the guy created a function body to copy for other functions. That would save him writing the exception handling block over and over again when a new function is added. No coding horror, though it might look like one at first view.
Maybe he didn't know about code snippets....
-
I blame VB 1, 2 and 3. I was a toddler at that time so I wouldn't know, but this is what I heard. VB became object oriented at version 4, but to be backwards compatible MS had to support the non-object oriented style. As a result many VB programmers kept on programming like they always did and still do so today. Why not C#? Because the first C# came at around the same time as VB4 and was object oriented right from the start. On a side note, try to call any PUBLIC member of a Form in VB without having an instance of the Form. It will work, you can call them as if they were Shared (static). I recently found out and was shocked, backwards compatibility with VB1... X| Anyway, I don't really blame VB, I blame the programmers who were not willing to learn object orientism right after VB3 :sigh: Does that sound about right or am I really way off here?
It's an OO world.
Naerling wrote:
VB became object oriented at version 4
Not fully, still lacked lots of OO principles, even VB 6 (like something as basic as inheritance).
Naerling wrote:
I blame the programmers who were not willing to learn object orientism right after VB3
I actually seen that in action on VB.Net.
Naerling wrote:
Does that sound about right or am I really way off here?
Yes, it does. But in my opinion that's not the full story and the full story about all the VB infame does not apply to everyone and to all scenarios. But yes, the word VB gives me goose bumps, specially when I learn I have to work with existing code.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
Naerling wrote:
VB became object oriented at version 4
Not fully, still lacked lots of OO principles, even VB 6 (like something as basic as inheritance).
Naerling wrote:
I blame the programmers who were not willing to learn object orientism right after VB3
I actually seen that in action on VB.Net.
Naerling wrote:
Does that sound about right or am I really way off here?
Yes, it does. But in my opinion that's not the full story and the full story about all the VB infame does not apply to everyone and to all scenarios. But yes, the word VB gives me goose bumps, specially when I learn I have to work with existing code.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
I had to work with lots of existing VB code... Code that goes as far back as being coded in VB6 and imported to .NET (when I started to learn programming there I learned from seeing what NOT to do) :omg: Luckily my hard studies got me to a point where my boss actually lets me write new classes and libraries for every programmer in the company (that's 4 people including me...) to use (and yes, I am one of those VB programmers who DOES know what an Interface (other than GUI) is and how to use it) :D
It's an OO world.
-
I had to work with lots of existing VB code... Code that goes as far back as being coded in VB6 and imported to .NET (when I started to learn programming there I learned from seeing what NOT to do) :omg: Luckily my hard studies got me to a point where my boss actually lets me write new classes and libraries for every programmer in the company (that's 4 people including me...) to use (and yes, I am one of those VB programmers who DOES know what an Interface (other than GUI) is and how to use it) :D
It's an OO world.
Naerling wrote:
my boss actually lets me write new classes and libraries for every programmer in the company to use
Now, that's really cool. It's a very nice role to have.
Naerling wrote:
and yes, I am one of those VB programmers who DOES know what an Interface (other than GUI) is and how to use it
Some may consider you a mythical character :laugh:
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
Naerling wrote:
my boss actually lets me write new classes and libraries for every programmer in the company to use
Now, that's really cool. It's a very nice role to have.
Naerling wrote:
and yes, I am one of those VB programmers who DOES know what an Interface (other than GUI) is and how to use it
Some may consider you a mythical character :laugh:
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
Fabio Franco wrote:
Some may consider you a mythical character
Thanks! :laugh:
It's an OO world.
-
I was refactoring a horribly written app. Tons of duplicated code. Crazy amounts of dead code (~30-50%). And my personal favourite, was a method that went something like this.
public void Some_Method()
{
try
{} catch (Exception x) { LogException(x); }}
Fortunately, or not, this method was never called...but I sure am glad the catch block was there....just in case that empty try block failed.
I feel your pain. I've just finished going through a similar process. After a while you stop getting annoyed and start laughing. The one that made me laugh most was:
public class OrderName
{
public String getName {
return "Order";
}
}That was the class in totality. One method that returned a hard coded value. [EDIT] I just found a better one:
for (int i = 1; i < 2; i++) {
//Code was here
}"You get that on the big jobs."
modified on Sunday, August 14, 2011 10:23 PM
