Consider providing property accessors for fields instead of making them public.
public struct Point { int x; int y; public Point(int x, int y) { this.x = x; this.y = y; } public int X { get { return x; } set { x = value; } } public int Y { get { return y; } set { y = value; } } }
To expose a field to a subclass, use a protected (family) property that returns the value of the field.
public struct Control : Component { int handle; protected int Handle { get { return Handle; } } }
By not exposing fields directly to the developer, the class can be versioned more easily. The reasons are (a) that a field cannot be changed to a property while maintaining binary compatibility and (b) that the presence of executable code in getters and setters allows later improvements, e.g., demand-creation of an object upon usage of the property, or a property change notification.
public struct Int32 public static readonly int MaxValue = 2147483647 public static readonly int MinValue = -2147483648 }
Spell out all the words used in a field name. Only use abbreviations if developers generally understand them. Do not use uppercase for field names. For example:
class Foo { string url; string destinationUrl; }
If there are predefined instances of an object, declare them as public readonly static fields of the object itself. Use pascal casing because they are public. For example:
public struct Color { public static readonly Color Red = new Color(0x0000FF); public static readonly Color Green = new Color(0x00FF00); public static readonly Color Blue = new Color(0xFF0000); public static readonly Color Black = new Color(0x000000); public static readonly Color White = new Color(0xFFFFFF); public Color(int rgb) { } public Color(byte r, byte g, byte b) { } public byte RedValue { get {...} } public byte GreenValue { get {...} } public byte BlueValue { get {...} } }