Coding usage and misusage, please lets talk about it

[Mike]

@Robin Overgaard

@Mike

@Robin Overgaard

[quote]Strings are immutable–the contents of a string object cannot be changed after the object is created, although the syntax makes it appear as if you can do this. For example, when you write this code, the compiler actually creates a new string object to hold the new sequence of characters, and that new object is assigned to b. The string “h” is then eligible for garbage collection.

Taken from Built-in reference types - C# reference - C# | Microsoft Learn

True, but this has nothing to do with the use of “” versus String.Empty.

Only due to, as mhectorgato pointed out, garbage collection.
[/quote]

What garbage collection? Internally they both refer to the identical object. Why would they be handled differently?

[Robin_Overgaard]

@Mike

@Robin Overgaard

@Mike

@Robin Overgaard

[quote]Strings are immutable–the contents of a string object cannot be changed after the object is created, although the syntax makes it appear as if you can do this. For example, when you write this code, the compiler actually creates a new string object to hold the new sequence of characters, and that new object is assigned to b. The string “h” is then eligible for garbage collection.

Taken from Built-in reference types - C# reference - C# | Microsoft Learn

True, but this has nothing to do with the use of “” versus String.Empty.

Only due to, as mhectorgato pointed out, garbage collection.

What garbage collection? Internally they both refer to the identical object. Why would they be handled differently?
[/quote]

Ehm yes right, okay, well since they optimized that, then I guess there is no difference anymore.

[godefroi]

@Mike

I suspect at one point, an optimization was added to the compiler to use String.Empty for “”.

The compiler does no such thing. There is a clear difference in the compiled code (MSIL) between them. Note that the JIT most likely optimizes the call to [mscorlib]System.String::Empty out on the desktop framework, but there is no JIT on our devices, so it doesn’t.

The important thing to remember here is that [mscorlib]System.String::Empty is nothing but a public static field that contains a reference to the interned string “”. No more, no less. If you set a variable equal to “”, that variable will contain a reference to the same interned string that [mscorlib]System.String::Empty contains. It will not create a new variable, because string constants are interned.

Allow me to point out that this has always been like this. There is no optimization that happened that changed these facts.

[Architect]

Amen

[Gralin]

@Robin Overgaard

C# will wrap short in an Int16 object when created as an Int16 but ofcourse C# is cleaver enough to know that a Int16 can be casted directly to a short.

This is true for Java. As it was already said this is not the case in C#.

[Robin_Overgaard]

@Gralin

@Robin Overgaard

C# will wrap short in an Int16 object when created as an Int16 but ofcourse C# is cleaver enough to know that a Int16 can be casted directly to a short.

This is true for Java. As it was already said this is not the case in C#.

Yeah, I understand that, but it was highly debated during my studies. but never the less, this was more intented to get some good code examples out in the open, I decided that when I get abit more time I will provide what I believe to be good coding practices on the wiki or som other way. (Havnt decided that yet)

[godefroi]

A really good start is Microsoft’s own standards: C# Coding Conventions | Microsoft Learn

What we use around here is a slightly modified version of that.

[Bec_a_Fuel]

And what about this ?

void ProgramStarted()
        {
            string ChaineDeCaractères = MaMéthode();

        }

        string MaMéthode()
        {
            return "Toto";
        }

[twospoons]

The difference between upper and lower case are just aliases as mentioned. In addition, even using a boolean doesn’t save any memory unless you are talking about heap. All stack based variables (int, short, bool++) are 4 bytes, regardless of type (on a 32bit CPU) in MSIL.

Reading MSIL is the only way to know what really happens, the rest is speculations. And these rules can change whenever MS pushes out some update. In general I do agree with OP that using proper conventions is a good thing. I don’t really care what the convention is as long as every developer on the team uses the same one.

Regarding optimization; the more clever you try to be the harder it often is for the compilers to figure things out. Compilers are really really really good these days, so there is often no reason to be fancy.

The MS code standard for class libraries is a good starting point. Resharper is a good tool, but keep in mind that we are developing for micro controllers, so interfaces, sub classing, OO tricks and patterns might not be as smart to implement.

[Innovactive]

If you really want to know how CLR process and manages your code, I suggest to dissect IL processing by mean of a native debugger, as depicted in our (amazing ) post:

tinyclr.it

[Gralin]

I remember when i was in college we used this document as a starting point. I guess its little out dated now…

C# Coding Standards document

[Bec_a_Fuel]

Sorry for respawning this thread, but…

SubMain / Download .NET Coding Guidelines

104 pages of guidelines, for those about to rock (we salute you)

[taylorza]

@Bec a Fuel

Sorry for respawning this thread, but…

SubMain / Download .NET Coding Guidelines

104 pages of guidelines, for those about to rock (we salute you)

I had a quick scan of the document and having written coding guidelines for many different companies for C/C++, C# and VB.NET, I can tell you that this looks like an outstanding piece of work. I will definitely be referencing it. Thank you for sharing!