An interesting pattern for parsing ints

bardofspoons421

So, several times in this codebase (Though it seems to be limited to one developer... and the other developer that copies from the first), there's this wonderful pattern:

if (int.TryParse(msg.MSH.SendingFacility.NamespaceID.Value, out ParsedInt) == true)
{
	ThingID = ParsedInt;
}

if (ThingID == null)
{
	throw new Exception(ErrorMessages.ThingIDInvalid);
}

Disregarding the ==true bit, the whole second if statement could be gotten rid of just by inverting the int.TryParse result, and the extra assignment between ParsedInt and ThingID.

As an added bonus, there's a few spots where this pattern can lead to a crash:

GenericObject ri = GenericObject.ResidentSelectByProspect(eCode, ProspectID.Value, null);
if (int.TryParse(ri.Property01, out ParsedInt)) { ResidentID = ParsedInt; }
if (_Debug) { GenericObject.HL7IncomingMessageProcessLogInsert(eCode, HL7IncomingMessageID, "ResidentID: " + ResidentID.ToString()); }
if (ResidentID == null)

{

throw new Exception(ErrorMessages.ResidentIDInvalid);

}

GenericObject is a wonderful class that bugs me. Not only are there static methods hanging off of it that don't use the class or its members in any way, it's contents are Property01 through Property11, all strings. Instead of using, oh, I dunno, an actual DTO, so you don't have go guess what's in Property02, and then parse it. And if debug is set when ResidentID is null, boom. And this also in the file I mentioned in a previous post that, out of over 2500 lines in the file, less than 500 are unique.

The developer responsible for this keeps saying that the next release they're going to go through and clean up the code. But when you write new code that is a tangled mess of spaghetti like this, I seriously doubt he is that interested in improving this code base, or his own coding, since he has previously said (And I am not paraphrasing too much here): "I don't want to learn anything new unless I have to". With "anything new" being the various LINQ methods on collections (Not even database related stuff, just IEnumerable), or using an ORM for simple CRUD actions (most of this application), using parameterized SQL, or not deleting PDB files on the build sever so we can troubleshoot.

I need a drink. And it's not even noon on Monday.

DrPepper

@bardofspoons42 said:

"I don't want to learn anything new unless I have to"

The very definition of someone who should not be a software engineer.

lucas1

I am going to be forced to paste the most WTF cost I have ever read, it is so beautiful in the WTFness It is one of the few pieces of code.

aihtdikh

@lucas said:

I am going to be forced to paste the most WTF cost I have ever read, it is so beautiful in the WTFness It is one of the few pieces of code.

New Markov-chain bot?

Snowyowl

@aihtdikh said:

@lucas said:
I am going to be forced to paste the most WTF cost I have ever read, it is so beautiful in the WTFness It is one of the few pieces of code.
New Markov-chain bot?

No, just drunk.

JimLahey

@bardofspoons42 said:

GenericObject is a wonderful class that bugs me. Not only are there static methods hanging off of it that don't use the class or its members in any way

Don't you just love it? I swear there are developers out there who do everything R# suggests to them. I wonder if there's a way I can sneak "cleveland steamer your line manager's desk to debug" or "stick a fork in your leg to make this code run faster" into R#'s suggestion list?

Medinoc

@bardofspoons42 said:

if (_Debug) { GenericObject.HL7IncomingMessageProcessLogInsert(eCode, HL7IncomingMessageID, "ResidentID: " + ResidentID.ToString()); }

@bardofspoons42 said:

And if debug is set when ResidentID is null, boom.

If ResidentID is a nullable int, it won't cause a boom. The Nullable`1 class's ToString method simply gives you an empty string when the nullable has no value.

If ResidentID is an Object however, then it does go boom.

FrostCat

@lucas said:

I am going to be forced to paste the most WTF cost I have ever read, it is so beautiful in the WTFness It is one of the few pieces of code.

It's too small to fit in the margin, unfortunately.

lucas1

I got distracted yesterday while writing the post.