HELLLPPPPPP!

[pedro2555]

Capitalization has the exact same purpose as does indentation. A friend of mine, while learning Ruby, once said to me: "It is everything you expect from a programming language, plain English, case sensitive and indent sensitive."

Indentation allows you to visually identify code structure, and capitalization has the same, overall, function, allows you to identify, for instance, the accessibility of a variable.

Microsoft suggests two capitalization schemes: PascalCase and camelCase. (And a 'special case' when using acronyms)

 

For instance, accessibility identification should use this scheme:

 

If you see something like:

Class.variable

You know that the underlying definition of variable is:

private object variable;

As opposed to:

Class.Variable

Which would be implemented as:

public object Variable;

One very common thing to have in C# is:

class MyClass{   public object[] MyArray;   private object myObject;   public object MyObject   {      get      {         return myObject;      }      set      {         myObject = value;      }   }   public MyClass(object[] myArray, object myObject)   {      MyArray = myArray;      this.myObject = myObject;   }}

Microsoft provides a comprehensive set of guidelines for .NET development in their Framework Design Guidelines -> http://msdn.microsoft.com/en-us/library/ms229042(v=vs.110).aspx

Edited May 23, 2014 by pedro2555

[LordOfTheBongs]

i havent read through all of that link but i like to put underscore for private field referenced through public properties

 

i would write it as...

 

 

private object _myObject;public object MyObject{    get    {        return _myObject;    }    set    {        _myObject = value;    }}

 

because if i just saw myObject, i would assume it is not accessed in any way from other classes... while _myVar might be private but it still can be get or set from other classes

[Rugz007]

Guys guys why dont u make a another topic?

[julionib]

maybe its because im not a coder, i just kid with coding, for example, i never heard about that "camel case" that you said ^^

Guys guys why dont u make a another topic?

 

lol, ok i will stop ^^

[Rugz007]

You are not a coder

[pedro2555]

i havent read through all of that link but i like to put underscore for private field referenced through public properties

 

i would write it as...

private object _myObject;public object MyObject{    get    {        return _myObject;    }    set    {        _myObject = value;    }}

because if i just saw myObject, i would assume it is not accessed in any way from other classes... while _myVar might be private but it still can be get or set from other classes

 

Actually the usage of underscore is dis encouraged by Microsoft's Design Guidelines for .NET. Quoting them:

 

√ DO choose easily readable identifier names.

For example, a property named HorizontalAlignment is more English-readable than AlignmentHorizontal.

√ DO favor readability over brevity.

The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).

X DO NOT use underscores, hyphens, or any other nonalphanumeric characters.

X DO NOT use Hungarian notation.

X AVOID using identifiers that conflict with keywords of widely used programming languages.

 

The scheme I've presented is the one suggested and used by Microsoft (and me ), but that's up to you.

Edited May 23, 2014 by pedro2555

[NTAuthority]

i believe u use the underscore for private fields refrenced through public properties

barely see a reason for not using automatic properties anyway

[LordOfTheBongs]

 

i believe u use the underscore for private fields refrenced through public properties

barely see a reason for not using automatic properties anyway

 

well sometimes u need to wrap some extra code when setting or getting a value

 

 

private int myVal;public int MyVal{    set    {        OnMyValSet(EventArgs.Empty);        myVal = value;    }}

 

something like that

Edited May 23, 2014 by LordOfTheBongs

[NTAuthority]

well sometimes u need to wrap some extra code when setting or getting a value

 

 

something like that

even though it's only an example I still feel the need to point out the Property Design section in the Member Design Guidelines stating the following:

 

X DO NOT provide set-only properties or properties with the setter having broader accessibility than the getter.

For example, do not use properties with a public setter and a protected getter.

If the property getter cannot be provided, implement the functionality as a method instead. Consider starting the method name with Set and follow with what you would have named the property. For example, AppDomain has a method called SetCachePath instead of having a set-only property called CachePath.

Edited May 23, 2014 by NTAuthority

[LordOfTheBongs]

yeah it was just an example and i guess this would be better for a method... tbh i didnt even know that, it makes sense though.

[pedro2555]

Guys guys why dont u make a another topic?

lol.

 

Why? Doesn't the discussion meet the topic title? I think it does.

Edited May 24, 2014 by pedro2555