Worst part of coding lang I love?

C# being case-sensitive.

Not a C# language thing, but I hate the vilification and anti-coding standard of not 'allowing' prefixes. Interfaces are allowed (ex. IUpdateCustomer), why not classes? Why can't I have a DTO and declare it a TCustomer and the zealots not scream "HE'S USING HUNGARIAN NOTATION!!! TAKE HIM TO THE STAKE!!"?

IMO, even "I" prefix is excessive. The name should be descriptive enough and end user should not be concerned about whether it's an interface or a class unless he's constructing an object.

@iiii says the guy with 4 i's in their name

@alexbrooklyn Dude has so many Is that he doesn't want to see them anywhere else.

Who says you can't name you're classes like that. If you have a valid reason to do something what do you care what others think? Don't constrict yourself to norms you don't agree with!

@iiii > "The name should be descriptive enough"

I 100% agree and that is the trick, isn't it? What is descriptive to me on 12-14-2020, will likely make zero sense to me (or anyone else) on 12-14-2022. :)

Me: "Who is the idiot who created the Ocr class? It should have been named OpticalCharacterRecognition. Let me look at the history ...oh...that was me."

There's nothing stopping you from IDerpMonster as a class, aside from convention. It's just stylistics.

I would burn you at the stake for hungarian notation though. It literally serves no purpose anymore.

@alexbrooklyn it would be one if system allowed. The shortest name is 4 symbols here

@12bitfloat > "Who says you can't name you're classes like that"

Microsoft coding standards, Visual Studio, SonarQube, the C# coding nazis, etc. Its more difficult/impossible to justify why I should change the standard if I'm the only one who is 'different'.

Coming from a Visual Basic -> Delphi -> now C#, I've adapted.

@PaperTrail Bold of you to assume I care about what Microsoft's coding standards say though

@12bitfloat
If it's only a Microsoft standard, it's not a standard at all, really. 😸

I can't resist this topic, it's so good.

Yeah, I never liked the "I" prefix for interfaces. If you're structuring your code right It's already in the "interface" package/directory!

Then again, as many said It's just a stylistic thing. I like it my way, you like it your way... If im commiting into your repository I will abide by your style and if you commit to mine I expect you to follow mine! It's just common courtesy

@Hazarth this convention is not nearly as bad as the convention to have Literally Everything Capitalized except local variables.
You want to name your property the same as it's type? Well too bad! Pick another name by appending 'Object' or 'Instance' which sounds retarded.

@Lensflare This works for me? Where is the Problem?

@Lensflare i agree, we should have type properties:
has no name, only type. gets returned when you try to cast/assign said object into (a variable of) that type.

yeah, that's basically just typecasting, but syntax for implementing that is too wordy and obnoxious.

class Person {
public string = "Person's Full Name"
}

much better

type property getter/setter

class Person {
public string (){
return "whatever string you want)
}

public void (string val){
this.whatever = val;
}
}

i'm only half-joking. i've been toying with this idea for a while

@Midnight-shcode exists in C++.

@iiii " The name should be descriptive enough"

Could you name some descriptive interface names as examples?

For instance, how would you make this more descriptive?
interface Animal
{
void run();
void makeSound();
}

@iiii with a syntax similar to my example? how is it called in there? don't tell me it's "type property", i hate when the names i give to the wheels i reinvent are already taken by existing wheels of the same purpose (and looks)

@jiraTicket why do you think it's not descriptive?

@Midnight-shcode
https://en.cppreference.com/w/cpp/...

@hypervtechnics I think the issue will be clear when you embed the type declaration into the class containing the property of the other type. The compiler will complain that it's not clear if you are referring to the type or the property name within that context.

Example:

class Toy {
enum Size { Small, Normal, Big }

public Size Size { get; set; } // oops!
}

Since Size is embedded into Toy, it's implicitly documented and the context is clear. It's not some arbitrary Size but a Toy Size. This is a nice tool to write good code unless the language conventions ruin it for you.

@Lensflare Ah okay. Didn't think that far...

@iiii Oh, my bad, I misread you and thought you were arguing that the name should indicate it was an interface - without using an I-prefix.

Now I see you're arguing there should be no naming difference between classes and interfaces at all as it shouldn't be a concern for the developer using it. Gotcha.