Dude what the fuck with C#'s code style?

Pascal case variable names and classes? Don't we do this so we can differentiate between variables and classes??

Newline between parentheses and brackets?

Retarded auto get/ set methods that serve no purpose than to make code difficult to read and debug?

And after all that shit, string, which is a class, has a lowercase s and is treated as if a primitive?

I really have no idea why this language is so widely praised. The only thing I like about it is that it's the only major bytecode language that has operator overloading and reference parameters.

As someone taking a C# class this semester, I feel your pain.

I thought it would be good to take some upper division classes that keep me stretching outside my development comfort zone as I'm wrapping up my degree.

C# has me stretching a little more than I thought 😂

@bhouston It's one of the better bytecode languages, but God, it could be so much better. All these little stupid deviations from standard c-family language attributes makes it so frustrating to work with.

@AlgoRythm Fair point.

Don't get me started on Visual Studio though!

🤢

It's not unusable but it's definitely far from ideal in my opinion. it always seems so... unintuitive. There are so many time I find myself getting lost in the VS interface. It always seems to feel cluttered no matter how I try to arrange the tabs and tools.

¯\_(ツ)_/¯ Matches C# in a lot of ways I suppose.

@bhouston I agree that VS is pretty damn cluttered. VSC is organized nicely.

@jespersh If it only applies to the next line then don't use brackets!

The fact that c# allows both String and string is retarded and inconsistent.

Why would you use attributes that hide the fact that code is being run behind the scenes? If you need to transform that data in some way, it makes more sense to use a member function! Otherwise it gives the impression that the data has no operation applied to it, and that can fuck with your debugging.

@AlgoRythm Agreed. I do have to admit VSC is pretty. I wouldn't says it's perfect but it did manage to pull me away from Atom.

Way better extension management and load times.

@jespersh Hey that's pretty cool! Thanks for the tip! I'll have to see if this improves my workflow on my next project.

Long time C# dev:

camelCase variables, Pascal types, not sure who told you variables are Pascal too. 🤷‍♂️

Auto properties are fine, they’re a bit clunky sometimes, mostly during construction, there was a proposal to simplify this but it’s been delayed. 🤷‍♂️

Attributes doing spooky magic is both good and bad, like anything else, it can be abused.

I personally really enjoy the language, not as much as I enjoy F# mind, but C# has been drifting closer and closer to a hybrid of the two for a while now, and I’m okay with it.

Each to their own I suppose.

And as for String vs string and Int32 vs int there’s a reason for it, reference types all auto inherit from base type Object, but value types like int can’t because they’re primitive types.

So the upper cased versions of the primitive types are a reference-type “box” for primitive values, to enable reference-type semantics over them.

It’s not nice sometimes, and they probably could have solved it a little nicer, but it works and it’s honestly not a problem, 9/10 you never need to interact with the reference-type versions directly as it does it automatically (it’s called “boxing” and “unboxing” respectively).

The auto property @Brolls is talking about is implemented.
The nice thing about the get set is you can do:
public string Test {get; private set;}

And variables are snakecase, properties are indeed pascal case. Attributes are snakecase.
I think its done to differentiate visually between public and not public properties/attributes.

Pascal case variable names? That isn't really part of the normal styles. And what do you mean "auto get/set methods"? Are you talking about properties? Because they're brilliant when it comes to write nice looking code.

And what do you get from not treating string as a primitive stylistically?

"string" ALWAYS gets me, and then pisses me off.

@Brolls not quite

int is just an alias for System.Int32 (just as string is an alias for System.String) and it implicitly inherits Object via System.ValueType (as all structs and enums do)

It's absolutely normal.

@simpleauthority i have the same when doing Java but not when doing C++

This is personal preference territory so I'll just make some corrections, no judgment.

- You use PascalCase only for PUBLIC Properties and Classes. Private fields and local variables use camelCase.

- The newline stuff, meh. I like newline between parentheses, more readable for me.

- What's retarded is how Java does it. You need to declare a private variable there, then write 2 methods to get the value and to set it. C# compiler does a massive favor to you by giving you the auto properties. Also, if you are putting complicated code in the getter or setter part of the auto property, you are better of moving it to its own method. Auto properties should behave like they already know the value.

- There is a 'String' class (with capital S) and C# designers provided a 'string' keyword (with small S). Generally the rule is: if it is a variable, use 'string'. If you need to access its static methods, use 'String'

- Awesome debugger, great runtime, perfect generics, attributes... etc...

@AlgoRythm "The fact that c# allows both String and string is retarded and inconsistent."

It does the same for Int32 and int

It is easier to type int than Int32.. long is easier than Int64 and so on... it is for this reason you have String and string.. so it is consistent with other types.

Int64 -> Class

long -> keyword

Int64.TryParse() <--- Correct

long.TryParse() <-- Works... just don't

Variable names should not be Pascal case! It's in the official guidelines that they should be camel case.

Newlines are a matter of personal preference, brackets can be placed on the same line or a new line.

The auto get/set methods are there to make our lives easier by writing less code. Public fields are by definition to be avoided. In C# we use properties. And although auto properties seem useless, in fact, they provide for proper encapsulation, so a developer can always change the implementation of the property if needed without breaking the public interface.

String and string are just aliases, although there is a small difference. The primitive types are always all lower case, although you can use their Pascal case alias too.

Personally, I always use the lower case and use the Pascal case only when calling a static method, e.g.:

int x = 1 + Int32.Parse("2");

It's better than this stupid Java code convention