Comment On Common Functions, not Common Sense

Ben inherited a an application from a fellow employee on the fast track to retirement. How fast? Well, these are some sample methods in a thousands-of-lines-long class file called, appropriately, "Functions". public static string ReturnEmptyStringIfNullElseValue(string value) { if (value == null) { return ""; } else { return value.ToString().Trim(); } } [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Common Functions, not Common Sense

2012-08-09 19:57 • by John Hensley (unregistered)
Why does this only happen in software? Why, for example, is the auto industry not plagued with self-taught inventors who can't be bothered to understand the combustion cycle, so they produce car designs with coal-fired engines?

Re: Common Functions, not Common Sense

2012-08-09 20:10 • by Some Jerk (unregistered)
386859 in reply to 386857
John Hensley:
Why does this only happen in software? Why, for example, is the auto industry not plagued with self-taught inventors who can't be bothered to understand the combustion cycle, so they produce car designs with coal-fired engines?


it isn't the industry that fails to comply with the standard... it is your imagination that fails to comply with the concept. Think about it... how many recalls happen each decade by some auto manufacturer that made a defective seatbealt... or the power stearing pump was not rated for specific weather conditions? it is the same thing in every industry. 95% of people are there for the paycheck. 4% are there because they love their jobs... and want to be the best at it... and what is between... well... who knows?

Re: Common Functions, not Common Sense

2012-08-09 22:36 • by AnonymousCoder (unregistered)
386865 in reply to 386778
I've got a class with 10,000 (that's right, TEN THOUSANDS) lines, and growing.
Wait till I show you what's in there ! It's a horror story !

I just can't wait....and unless you posted it last week, it probably won't happen in my lifetime...


Sarcasm aside - Oh I wish ! I wish to let it out, to burst into a rant over the code that's being written at my company - but there's one thing holding me. That's the Non Disclosure Agreement. And a few of the clauses in my contract, which explicitly prohibit me from bad mouthing the company or discrediting it.

One day - I'll do it.

The code is just so bad, it has to be exposed. It's a classic. Has everything - string arithmetic; procedural design in an OOP language; God class; lots of static classes with static methods and (lo and behold) public static fields; error handling by hiding - yes, it's the most blatant feature - exceptions are just swallowed (granted - not everyone); unchecked, unaccounted for global variables (you may think, hey - it's C#; don't matter, make singleton variables and mark them static); event handlers driven design, as substitute for polymorphism (of course, if you only have one class, you need handlers); dead code; commented blocks of junk which lay there for no reason; SQL database "layer" where you have to plug in parameters by index, longest sequence attaining 33 params (how the HELL could possibly a human keep track of that ?!)

-- A freaking jungle layed out with mines. God, I love to hate it...

Re: Common Functions, not Common Sense

2012-08-10 00:15 • by default_ex (unregistered)
386866 in reply to 386823
Craig's friend:
TRWTF is really these arrogant kids with shallow knowledge not willing to understand why certain things are done in certin ways. Sure, string to string looks real stupid, but guys, it may be written by someone who is maybe less intelligent than you are.


I sort of agree with you on this point. Having worked with a wide variety of people I've grown to be more understanding, but there is a limit.

The most important thing to consider with a programmer is that they'll be solving logic and math every time they go to work on a piece of code. Anyone that's put in the effort to learn the language well enough to write clumsy code is likely willing to learn more advanced concepts that'll turn them from a poor coder to a good coder.

The one point in your post that's most important is the why. All too often we see things posted on code websites with little or no explanation on why it works or how it works. That's the most important thing to know, otherwise we just breed more copy-paste coders.

However if someone is truly not intelligent enough to write decent code after a being given a fair chance to do so. Then their in the wrong field and will only endanger other people if their allowed to continue on as programmers. We have no way of knowing just how important our programs will be, for all we know the stuff could wind up being a core tool in a financial empire. We're in a position to do so much damage if our work screws up, that makes it our number one priority to ensure we remove as many fail clauses as possible.

Re: Common Functions, not Common Sense

2012-08-10 05:15 • by Cbuttius
386873 in reply to 386857
John Hensley:
Why does this only happen in software? Why, for example, is the auto industry not plagued with self-taught inventors who can't be bothered to understand the combustion cycle, so they produce car designs with coal-fired engines?


Maybe because in all other industries they go through some formal qualification with a recognised professional body, in your case engineering.

With software there is no real formal qualification and people are usually hired because they have the right buzzwords on their CV/resume, where longevity in a firm is seen as a plus (albeit they may have got set in their incorrect ways seeing only one way of doing something) often stuck in a system that has moved on. So even if this wasn't written a long time ago here, the person may have brought this in from the way they did this in their previous company.

Re: Common Functions, not Common Sense

2012-08-10 05:55 • by Cbuttius
1. Generic code is code that is not attached to any particular business logic and is commonly used all over your code.

Having to put it into a class is a WTF'ery of the language because classes are not extendable. In C++ you would make these free functions and probably put them in a namespace. You can then write more functions as you need them and put them into the same namespace but in a different file. True that if they all build into one common shared object library you need to rebuild that library for those who want to use the new functions but it is still adding rather than editing. (If your build makefile uses a wildcard you don't need to modify that either). Whatever, having them in one file is a WTF of the language.

This is because they insisted that it had to be "pure OO" and thus everything attached to an object. Purism over practicality.

2. Having a function both strip whitespace and also convert null to empty string is not a WTF. The implementation used might be although I can't see it here. The name might be better and for commonly-used library code, finding good names for things is more essential. But then even some of the best known systems are known for poor naming choices.

Probably far too late to change the names now, my guess is that they are already all over the code.

3. Some of the others might be good contenders for using a regex and could possibly even be done as one-liners using them, but regexes look ugly in business code and don't belong there. I would rather see something like StringConversions.GetPrice( input_string ) in my business code than some horrible regex.

Re: Common Functions, not Common Sense

2012-08-10 06:41 • by RayvenUK (unregistered)
386882 in reply to 386695
Bob:
I agree with Mr. Time and Space here. Code monkeys, as a breed, are far too eager to start shooting down everybody else's thinking. I believe it's because a lot of us have insecurities about our own abilities and by shooting first all the time it deflects attention from our own weaknesses and makes us feel better about ourselves. It's the one part of this field that really irks me. It's in other fields, too, but it seems to be rampant around programming in general.


I object to being called a Code Monke..... oooh, a digital banana, yum.

Re: Common Functions, not Common Sense

2012-08-10 07:32 • by no laughing matter
386897 in reply to 386875
Cbuttius:
1. Generic code is code that is not attached to any particular business logic and is commonly used all over your code.

Having to put it into a class is a WTF'ery of the language because classes are not extendable.
Well, that is not true for all OO-languages. E.g. Ruby and Smalltalk allow to extend existing classes. Not claiming that this really is a good idea: When multiple programmers work on the same codebase, there definitely is a risk of collisions.

Cbuttius:

In C++ you would make these free functions and probably put them in a namespace.
Well, in a true OO language "everything is an object" and in a class-based OO-language an object is an instance of a class.

So in such a true OO-language a namespace is an object, too, and there is no difference between putting the function in a namespace vs. adding a method to a class.

Cbuttius:

You can then write more functions as you need them and put them into the same namespace but in a different file.
The rule that a class must be defined completely in one file is specific to Java, other OO-languages are more permissive and a real Smalltalk is image-based, not file-based.

Cbuttius:

This is because they insisted that it had to be "pure OO" and thus everything attached to an object. Purism over practicality.
If your "they" means the inventors of the Java language then i won't object, but this claim of impracticality is not true for all OO-languages.

Cbuttius:

2. Having a function both strip whitespace and also convert null to empty string is not a WTF.
There's nothing wrong if it is a composition of two other functions, one for stripping whitespace and one for converting null to empty string.

This allows for all of these features to be used separately when needed. And this is exactly what's wrong with this code: Too much features lumped together in a single method, and when some of the features are needed again, they are "re-used" by Copy-and-Paste-programming.

Cbuttius:

Probably far too late to change the names now, my guess is that they are already all over the code.
That's exactly what's refactoring is for, and refactoring works like a charm in Java and C# (it's much harder but still more-or-less works in dynamically-typed languages).

But even when refactoring is not available: rename the function, and add a function with the old name to call your new function and mark the function with the old name as deprecated.

If something is ill-named and you have to keep it for compatibility-reasons at least show a warning (e.g. by marking it as deprecated).

Re: Common Functions, not Common Sense

2012-08-10 08:16 • by Some Jerk (unregistered)
386908 in reply to 386875
Cbuttius:
1. Generic code is code that is not attached to any particular business logic and is commonly used all over your code.

Having to put it into a class is a WTF'ery of the language because classes are not extendable. In C++ you would make these free functions and probably put them in a namespace. You can then write more functions as you need them and put them into the same namespace but in a different file. True that if they all build into one common shared object library you need to rebuild that library for those who want to use the new functions but it is still adding rather than editing. (If your build makefile uses a wildcard you don't need to modify that either). Whatever, having them in one file is a WTF of the language.

This is because they insisted that it had to be "pure OO" and thus everything attached to an object. Purism over practicality.

2. Having a function both strip whitespace and also convert null to empty string is not a WTF. The implementation used might be although I can't see it here. The name might be better and for commonly-used library code, finding good names for things is more essential. But then even some of the best known systems are known for poor naming choices.

Probably far too late to change the names now, my guess is that they are already all over the code.

3. Some of the others might be good contenders for using a regex and could possibly even be done as one-liners using them, but regexes look ugly in business code and don't belong there. I would rather see something like StringConversions.GetPrice( input_string ) in my business code than some horrible regex.


Getting to the obvious point here... c++ is c++ and .NET is .NET. If every language conducted things the same way, then there would be only 1 development environment.

Yes... template functions are definately handy... but for those of us who don't use c++ every day, generic classes and methods are more consistent with our own daily workflow.

Regex DOES belong in business code... for validation purposes most especially. I disagree with using it for data type conversions, but that is possibly more preference than anything.

Re: Common Functions, not Common Sense

2012-08-10 19:46 • by Craig's friend's friend (unregistered)
386993 in reply to 386828
no laughing matter:
So false! As already explained by nisl, he was using TryParse, so he was using at least .NET 2.0.

FAIL FAIL FAIL. Just because you read others codes with VS2015, it doesn't mean the original programmer actually written the code with .NET 2.0.

Jon Haugsand:
Bad coding, yes, but hardly a WTF.


Re: Common Functions, not Common Sense

2012-08-10 20:13 • by Nagash (unregistered)
Sir, me wrote Parse, then come along Nagash's friend changed it to TryParse. Nagash's friend was proud of himself saving an exception on error resume next. Tmr it ain't laughing matter when you look at it from VS2020 the whole thing WTF!?!
Me happy to receive support call my customer always happy

Re: Common Functions, not Common Sense

2012-08-13 10:50 • by Neil (unregistered)
387061 in reply to 386759
Nagesh:
This ain't being necesary as Java having no null check on parse of Integar from String for performing reason.
String str = "13";

int n = -1;
try {
n = Integer.parseInt();
catch (NumberFormatException ex) {}
catch (NullPointerException ex) {}
return n >= 0;


This is meking Nagesh mother cry.
Don't show her this then:
int n = -1;

try {
n = Integer.parseInt(str);
} finally {
return n;
}

Re: Common Functions, not Common Sense

2012-08-16 23:27 • by Late_in_the_game (unregistered)
387468 in reply to 387061
public static bool isNumeric(string value)
{
bool isNum = true;
for (int i = 0; i < value.Length; i++)
{
if (!"1234567890".Contains(value.Substring(i, 1)))
{
isNum = false;
}
}
return isNum;
}

Somebody might have already picked this up, but this method will only return false if the LAST char in value is not a digit.
I can understand doing it this way instead of, say, trying to parse it and handling the exception, because throwing and catching an exception is relative expensive.

2c

Re: Common Functions, not Common Sense

2012-08-23 08:24 • by JM (unregistered)
387976 in reply to 386691
I might excuse your post if you lack complete knowledge of C# in specific...and 'good programming patterns' in general.

This post was one of the best WTFs recently.

Anyone that doesn't think so should think long and hard as to why they don't get it.

Re: Common Functions, not Common Sense

2012-08-23 08:25 • by JM (unregistered)
387977 in reply to 386691
Above post was in regards to:

Infinite Time and Space:
There is no WTF here. These functions give you flexibility to handle cases that apply to your situation that the built-ins may not have. Putting them in one class supports easy refactoring. Also, this is a common and reasonable solution when the best available programmer is someone unfamiliar with all of the built in functions of a language. We get paid to get a good enough job done as efficiently as possible. Writing the world's greatest code is often contrary to that. The side effect is that experienced programmers often have to go in and clean up someone else's mess to add new features that the original planners could not have possibly foreseen. It is what we are paid to do. Deal with it or pick another career.


Reply didn't inject any quote.

Re: Common Functions, not Common Sense

2012-10-02 21:26 • by nelson_no_nose (unregistered)
391467 in reply to 386865
AnonymousCoder:
I've got a class with 10,000 (that's right, TEN THOUSANDS) lines, and growing.
Wait till I show you what's in there ! It's a horror story !

I just can't wait....and unless you posted it last week, it probably won't happen in my lifetime...


Sarcasm aside - Oh I wish ! I wish to let it out, to burst into a rant over the code that's being written at my company - but there's one thing holding me. That's the Non Disclosure Agreement. And a few of the clauses in my contract, which explicitly prohibit me from bad mouthing the company or discrediting it.

One day - I'll do it.

The code is just so bad, it has to be exposed. It's a classic. Has everything - string arithmetic; procedural design in an OOP language; God class; lots of static classes with static methods and (lo and behold) public static fields; error handling by hiding - yes, it's the most blatant feature - exceptions are just swallowed (granted - not everyone); unchecked, unaccounted for global variables (you may think, hey - it's C#; don't matter, make singleton variables and mark them static); event handlers driven design, as substitute for polymorphism (of course, if you only have one class, you need handlers); dead code; commented blocks of junk which lay there for no reason; SQL database "layer" where you have to plug in parameters by index, longest sequence attaining 33 params (how the HELL could possibly a human keep track of that ?!)

-- A freaking jungle layed out with mines. God, I love to hate it...


This sounds so similar to a couple of the places I've worked. I've seen my share of God classes of tens of thousands of lines and megabytes in size which wouldn't be so bad if they at least weren't so messy with inconsistency as far as the eye can see. One was even called "Functions". Commented out code everywhere and renamed files that are no longer used. Worst still, swaths of obsolete code that is still executed but to no effect other than generating heat. Layers of indirection so deep that a call trace has more steps than the Great Pyramid of Giza would if it were made of Lego bricks. Function names and inline langdoc that has nothing to do with what the function does. So much copy and pasted repeat code that someone coding it by scratch could make something with way less than half as many lines. Somehow managing to write something in 500 lines with no redundant code that could be rewritten in 50 lines while being more secure, featured, accurate, stable and efficient. Rosetta comments everywhere such as (bookshelf->addBook(book);//add book to bookshelf). It goes on and on.

What I find amazing is how pervasive these problems are. Whenever I think I have seen the worst of it, something else comes along. For a while I always wanted to expose it, but I've come to see so much of it that I just don't see the point of it.

Re: Common Functions, not Common Sense

2012-11-18 16:36 • by TigerShark (unregistered)
395126 in reply to 386784
Grzes:

To all of you defending this code: Learn to program proper!

This codebase is a huge W-T-clusterFuck.

(...)


I'm a programmer, not a philosopher, so I won't argue with such grandiloquent phrases as separation-of-concerns and single-responsibility-principle. I believe you are right (for most points), maybe in the Java world there is an emphasis on doing things in accordance to some specific doctrines and if it actually works is a secondary issue.

However, I don't agree with point 5. I strongly deem that using both words "Java" and "efficiency" in one sentence is a stylistic error, because these words are simply incompatible.

If you care about efficiency, don't use Java.
If you use Java, don't aim for efficiency, because this is something you already lost choosing Java.
Other than not being a philosopher you are neither a very good programmer if you are convinced that your obscene last two sentences are the Truth Revealed from God to humanity.
Writing code in java and in other higher level languages more often increases the efficiency since the programmer is free to concentrate on the real problem that he has to solve rather than in the language intricacies.
It is enough to take a look to the jruby performance and to compare it to the ruby reference implementation written in c++.
In most cases jruby is much faster than ruby.
So we can infer that java is always more efficient than c++?
Of course not, but for sure we can say that your Absolute Truth that so gently you revealed to us, poor mere subhuman programmers, is just a bunch of crap.

BTW I don't like java, I prefer much more c#.
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment