Representative struct

The_Assimilator

From the C# 2.0 codebase I'm currently digging through (while wearing a hazmat suit and cursing loudly):

    public enum RunStatus
    {
      [StringValue("COMPLETE")]
      COMPLETE,
      [StringValue("PROCESSD")]
      PROCESSD,
      [StringValue("WRITTEN")]
      WRITTEN,
      [StringValue("CREATED")]
      CREATED
    }

StringValue is an Attribute subclass that allows you to apply a string value to an enum field. Great, except there's the perfectly good Description attribute which already does the same thing, and has since .NET 1.1.

Oh, and that completely ignores the uselessness of defining a string value for an enum field when you can just call ToString() on the field. But the guys who wrote this system don't know about ToString() - except when they call it on strings. Yes, the codebase is littered with textBox.Text.ToString() calls.

Other WTFs include, but are not limited to:

calling Int32.Parse(comboBox.Value) multiple times in the same method, instead of doing the parsing once and saving the result in a variable
converting booleans to bytes by using Byte.Parse(value ? "1" : "0") instead of Convert.ToByte(value)
using Byte.Parse("0") multiple times instead of declaring and using a zero-valued byte variable
too many more to list...

Edit: I forgot my favourite, IT MAKES CONTROLS FALSE.

    private void SetControlsFalse()
    {
      lookupButtonEdit.Visible = false; 
      lookUpEdit.Visible = false;
      spinEdit.Visible = false;      
    }

Thief

Where's the representative struct? I only see an enum.

The_Assimilator

@Thief^ said:

Where's the representative struct? I only see an enum.

You also see my failure. Someone please change the thread title to save me from further embarrassment.

Smitty

@The_Assimilator said:

Oh, and that completely ignores the uselessness of defining a string value for an enum field when you can just call ToString() on the field. But the guys who wrote this system don't know about ToString() - except when they call it on strings. Yes, the codebase is littered with textBox.Text.ToString() calls.

I feel your pain. I recently discovered something similar in our codebase:

private void Foo()
{
    String sString = "some magic literal"; <-- couple WTFs here

    ...snip 100 lines...

    if (sString != null) <-- another WTF
    {
        String sString2 = sString.ToString().Trim().ToString(); <-- count the WTFs

...snip another 100 lines...
}

...snip yet another 100 lines...
}

While Foo() is obviously a made-up method name, sadly, sString and sString2 are the actual variable names I encountered. Shoot me now.

serguey123

@Smitty said:

I feel your pain. I recently discovered something similar in our codebase:

private void Foo()
{
    String sString = "some magic literal"; <-- couple WTFs here

    ...snip 100 lines...

    if (sString != null) <-- another WTF
    {
        String sString2 = sString.ToString().Trim().ToString(); <-- count the WTFs

        ...snip another 100 lines...
    }

    ...snip yet another 100 lines...
}

While Foo() is obviously a made-up method name, sadly, sString and sString2 are the actual variable names I encountered. Shoot me now.

If this makes you suicidal then you won't last long in this profession. I work with Oracle, enough said

boh

Please join me in my movement to outlaw ToString() and Parse() as functions. My guess is that we would see a lot less of this nonsense if everyone was forced to use them as statements instead.

Are the young programmers of today afraid of storing data in anything but strings? Are int:s dangerous in some way that I haven't realized?

tbhatcatbod

@The_Assimilator said:

Oh, and that completely ignores the uselessness of defining a string value for an enum field when you can just call ToString() on the field.

If the code is being obfuscated, it actually makes sense to not use ToString on enum values or types anywhere. Especially if the obfuscation guy and the guy writing the code are two different people. I'm not saying its the best way, but it isn't senseless.

@The_Assimilator said:

Great, except there's the perfectly good Description attribute which already does the same thing, and has since .NET 1.1.

DescriptionAttribute is NOT a general purpose class you can just throw whatever random string you want into. I'd consider using the description attribute here to be more of a WTF honestly.

@boh said:

Are the young programmers of today afraid of storing data in anything but strings? Are int:s dangerous in some way that I haven't realized?

They come from TCL. They haven't heard of ints. Or booleans. Let alone those mystical doubles.

OzPeter

@The_Assimilator said:

Oh, and that completely ignores the uselessness of defining a string value for an enum field when you can just call ToString() on the field. But the guys who wrote this system don't know about ToString()

Sometimes you want the text you display for an enum to be different from the string of the enum itself. In that case ToString() won't work. (And yes I know that it this case the two strings will be different - but it makes sense if this a design rule they are following)

hoodaticus

@Buzer said:

They come from TCL. They haven't heard of ints. Or booleans. Let alone those mystical doubles.

For which everyone with money is grateful.

The_Assimilator

@tbhatcatbod said:

@The_Assimilator said:
Oh, and that completely ignores the uselessness of defining a string value for an enum field when you can just call ToString() on the field.

If the code is being obfuscated...

It's not. These are guys for whom

string.Format()

using format specifiers is the height of programming zen; you really think they're going to know about obfuscation?

@tbhatcatbod said:

@The_Assimilator said:
Great, except there's the perfectly good Description attribute which already does the same thing, and has since .NET 1.1.

DescriptionAttribute is NOT a general purpose class you can just throw whatever random string you want into. I'd consider using the description attribute here to be more of a WTF honestly.

Why?

Description

does nothing more than store a string, it lives in System.ComponentModel which is part of System.dll and therefore is guaranteed to be available in 99.9% of C# apps you write, and its class name is perfectly... descriptive. And I've never come across a rule saying "only use it on components", even if that's what its namespace implies.

@OzPeter said:

@The_Assimilator said:
Oh, and that completely ignores the uselessness of defining a string value for an enum field when you can just call ToString() on the field. But the guys who wrote this system don't know about ToString()
Sometimes you want the text you display for an enum to be different from the string of the enum itself.

Not in this case!

@OzPeter said:

In that case ToString() won't work. (And yes I know that in this case the two strings will be different - but it makes sense if this a design rule they are following)

All the enums used in the project are defined in a single .cs file. Half of them have the StringValue attribute applied and look similar to the code I posted (i.e. StringValue == field name), the other half have no StringValues. And before you ask, no, the code wasn't autogenerated from a DB... again, that's WAY too sophisticated for the original devs.

TheCPUWizard

@The_Assimilator said:

Why?
Description
does nothing more than store a string, it lives in System.ComponentModel which is part of System.dll and therefore is guaranteed to be available in 99.9% of C# apps you write, and its class name is perfectly... descriptive. And I've never come across a rule saying "only use it on components", even if that's what its namespace implies.

In spite of DescriptionAtrtibute haging a Targets.All, the Summary sdescription clearly states "Specifies a description for a property or event."

Scarlet_Manuka

@Smitty said:

sString and sString2 are the actual variable names

At least they put the s in front. If they'd just been called String and String2, how would you ever have known the data type?

too_many_usernames

@Scarlet Manuka said:

@Smitty said:
sString and sString2 are the actual variable names
At least they put the s in front. If they'd just been called String and String2, how would you ever have known the data type?

Bwahahahaha!

(Take that either as maniacal laughter because I agree with the sentiment of S. Manuka and/or weeping because people actually (ab)use that form of notation.)

DaveK1

@TheCPUWizard said:

@The_Assimilator said:
Why?
Description
does nothing more than store a string, it lives in System.ComponentModel which is part of System.dll and therefore is guaranteed to be available in 99.9% of C# apps you write, and its class name is perfectly... descriptive. And I've never come across a rule saying "only use it on components", even if that's what its namespace implies.
In spite of DescriptionAtrtibute haging a Targets.All, the Summary sdescription clearly states "Specifies a description for a property or event."

It took you since February to think of that reply?

jasmine2501

What about http://msdn.microsoft.com/en-us/library/system.byte.minvalue.aspx

TheCPUWizard

@DaveK said:

It took you since February to think of that reply?

Nah, just that sometimes when I am stuck waiting for hours on machines, I "random arcticle" or even "random page" on the sidebar. 99.9% of the time I would not reply, but I guest this was the 1000th item that I hit <grin>

Weps

@Scarlet Manuka said:

@Smitty said:
sString and sString2 are the actual variable names
At least they put the s in front. If they'd just been called String and String2, how would you ever have known the data type?

Aren't they shorts?

da_Doctah

@Weps said:

@Scarlet Manuka said:
@Smitty said:
sString and sString2 are the actual variable names
At least they put the s in front. If they'd just been called String and String2, how would you ever have known the data type?
Aren't they shorts?

They prefer the term "persons of limited vertical dimension".

PJH

@da Doctah said:

@Weps said:
@Scarlet Manuka said:
@Smitty said:
sString and sString2 are the actual variable names

At least they put the s in front. If they'd just been called String and String2, how would you ever have known the data type?
Aren't they shorts?

They prefer the term "persons of limited vertical dimension".

Not "bifurcated garments?"

Someone_You_Know

@da Doctah said:

@Weps said:
@Scarlet Manuka said:
@Smitty said:
sString and sString2 are the actual variable names
At least they put the s in front. If they'd just been called String and String2, how would you ever have known the data type?
Aren't they shorts?

They prefer the term "~~persons~~ pants of limited vertical dimension".

FTFY.

Smitty

In that same codebase, some shithead also created this:

bool bBooleanValue = false;

... snip hundreds of lines ...

if (bBooleanValue == true) { ... various WTFery ... }

Yes, bBooleanValue was the actual variable name. Luckily I managed to get the hell out of that place.

Scarlet_Manuka

@Smitty said:

Yes, bBooleanValue was the actual variable name.

bHeardOfHungarianNotation = true;

bUnderstandHungarianNotation = false;