Knowledge Share
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Knowledge Share

Knowledge is NOT Power IMPLEMENTATION of knowledge is Power!!!
 
HomePortalGalleryLatest imagesRegisterLog in

 

 Coding Conventions in .net

Go down 
AuthorMessage
Admin
Admin



Posts : 142
Points : 59334476
Reputation : 0
Join date : 2007-12-29
Location : Chennai

Coding Conventions in .net Empty
PostSubject: Coding Conventions in .net   Coding Conventions in .net Icon_minitimeMon Dec 31, 2007 12:04 pm

Properties vs. Methods
Class library designers often must decide between implementing a class member as a property or a method. In general, methods represent actions and properties represent data. Use the following guidelines to help you choose between these options.
• Use a property when the member is a logical data member. In the following member declarations, Name is a property because it is a logical member of the class.
[Visual Basic]
Public Property Name As String
Get
Return m_name
End Get
Set
m_name = value
End Set
End Property
[C#]
public string Name
get
{
return name;
}
set
{
name = value;
}
• Use a method when:
• The operation is a conversion, such as Object.ToString.
• The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
• Obtaining a property value using the get accessor would have an observable side effect.
• Calling the member twice in succession produces different results.
• The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
• The member is static but returns a value that can be changed.
• The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code. In the following code example, each call to the Methods property creates a copy of the array. As a result, 2n+1 copies of the array will be created in the following loop.
[Visual Basic]
Dim type As Type = ' Get a type.
Dim i As Integer
For i = 0 To type.Methods.Length - 1
If type.Methods(i).Name.Equals("text") Then
' Perform some operation.
End If
Next i
[C#]
Type type = // Get a type.
for (int i = 0; i < type.Methods.Length; i++)
{
if (type.Methods[i].Name.Equals ("text"))
{
// Perform some operation.
}
}
The following example illustrates the correct use of properties and methods.
[Visual Basic]
Class Connection
' The following three members should be properties
' because they can be set in any order.
Property DNSName() As String
' Code for get and set accessors goes here.
End Property
Property UserName() As String
' Code for get and set accessors goes here.
End Property
Property Password() As String
'Code for get and set accessors goes here.
End Property
' The following member should be a method
' because the order of execution is important.
' This method cannot be executed until after the
' properties have been set.
Function Execute() As Boolean
[C#]
class Connection
{
// The following three members should be properties
// because they can be set in any order.
string DNSName {get{};set{};}
string UserName {get{};set{};}
string Password {get{};set{};}

// The following member should be a method
// because the order of execution is important.
// This method cannot be executed until after the
// properties have been set.
bool Execute ();
}

Read-Only and Write-Only Properties
You should use a read-only property when the user cannot change the property's logical data member. Do not use write-only properties.
Indexed Property Usage
Note An indexed property can also be referred to as an indexer.
The following rules outline guidelines for using indexed properties:
• Use an indexed property when the property's logical data member is an array.
• Consider using only integral values or strings for an indexed property. If the design requires other types for the indexed property, reconsider whether it represents a logical data member. If not, use a method.
• Consider using only one index. If the design requires multiple indexes, reconsider whether it represents a logical data member. If not, use a method.
• Use only one indexed property per class, and make it the default indexed property for that class. This rule is enforced by indexer support in the C# programming language.
• Do not use nondefault indexed properties. C# does not allow this.
• Name an indexed property Item. For example, see the DataGrid.Item Property. Follow this rule, unless there is a name that is more obvious to users, such as the Chars property on the String class. In C#, indexers are always named Item.
• Do not provide an indexed property and a method that are semantically equivalent to two or more overloaded methods. In the following code example, the Method property should be changed to GetMethod(string) method. Note that this not allowed in C#.
[Visual Basic]
' Change the MethodInfo Type.Method property to a method.
Property Type.Method(name As String) As MethodInfo
Function Type.GetMethod(name As String, ignoreCase As Boolean) As MethodInfo
[C#]
// Change the MethodInfo Type.Method property to a method.
MethodInfo Type.Method[string name]
MethodInfo Type.GetMethod (string name, Boolean ignoreCase)
[Visual Basic]
' The MethodInfo Type.Method property is changed to
' the MethodInfo Type.GetMethod method.
Function Type.GetMethod(name As String) As MethodInfo
Function Type.GetMethod(name As String, ignoreCase As Boolean) As MethodInfo
[C#]
// The MethodInfo Type.Method property is changed to
// the MethodInfo Type.GetMethod method.
MethodInfo Type.GetMethod(string name)
MethodInfo Type.GetMethod (string name, Boolean ignoreCase)
Event Usage Guidelines
The following rules outline the usage guidelines for events:
• Choose a name for your event based on the recommended Event Naming Guidelines.
• When you refer to events in documentation, use the phrase, "an event was raised" instead of "an event was fired" or "an event was triggered."
• In languages that support the void keyword, use a return type of void for event handlers, as shown in the following C# code example.
public delegate void MouseEventHandler(object sender, MouseEventArgs e);
• Use strongly typed event data classes when an event conveys meaningful data, such as the coordinates of a mouse click.
• Event classes should extend the System.EventArgs Class, as shown in the following example.
[Visual Basic]
Public Class MouseEventArgs
Inherits EventArgs
' Code for the class goes here.
End Class
[C#]
public class MouseEvent: EventArgs {}
• Use a protected (Protected in Visual Basic) virtual method to raise each event. This technique is not appropriate for sealed classes, because classes cannot be derived from them. The purpose of the method is to provide a way for a derived class to handle the event using an override. This is more natural than using delegates in situations where the developer is creating a derived class. The name of the method takes the form OnEventName, where EventName is the name of the event being raised. For example:
[Visual Basic]
Public Class Button
Private onClickHandler As ButtonClickHandler
Protected Overridable Sub OnClick(e As ClickEventArgs)
' Call the delegate if non-null.
If Not (onClickHandler Is Nothing) Then
onClickHandler(Me, e)
End If
End Sub
End Class

[C#]
public class Button
{
ButtonClickHandler onClickHandler;

protected virtual void OnClick(ClickEventArgs e)
{
// Call the delegate if non-null.
if (onClickHandler != null)
onClickHandler(this, e);
}
}
The derived class can choose not to call the base class during the processing of OnEventName. Be prepared for this by not including any processing in the OnEventName method that is required for the base class to work correctly.
• You should assume that an event handler could contain any code. Classes should be ready for the event handler to perform almost any operation, and in all cases the object should be left in an appropriate state after the event has been raised. Consider using a try/finally block at the point in code where the event is raised. Since the developer can perform a callback function on the object to perform other actions, do not assume anything about the object state when control returns to the point at which the event was raised. For example:
[Visual Basic]
Public Class Button
Private onClickHandler As ButtonClickHandler
Protected Sub DoClick()
' Paint button in indented state.
PaintDown()
Try
' Call event handler.
OnClick()
Finally
' Window might be deleted in event handler.
If Not (windowHandle Is Nothing) Then
' Paint button in normal state.
PaintUp()
End If
End Try
End Sub
Protected Overridable Sub OnClick(e As ClickEvent)
If Not (onClickHandler Is Nothing) Then
onClickHandler(Me, e)
End If
End Sub
End Class
[C#]
public class Button
{
ButtonClickHandler onClickHandler;

protected void DoClick()
{
// Paint button in indented state.
PaintDown();
try
{
// Call event handler.
OnClick();
}
finally
{
// Window might be deleted in event handler.
if (windowHandle != null)
// Paint button in normal state.
PaintUp();
}
}

protected virtual void OnClick(ClickEvent e)
{
if (onClickHandler != null)
onClickHandler(this, e);
}
}
• Use or extend the System.ComponentModel.CancelEventArgs Class to allow the developer to control the events of an object. For example, the TreeView control raises a BeforeLabelEdit when the user is about to edit a node label. The following code example illustrates how a developer can use this event to prevent a node from being edited.
[Visual Basic]
Public Class Form1
Inherits Form
Private treeView1 As New TreeView()

Sub treeView1_BeforeLabelEdit(source As Object, e As NodeLabelEditEventArgs)
e.CancelEdit = True
End Sub
End Class
[C#]
public class Form1: Form
{
TreeView treeView1 = new TreeView();

void treeView1_BeforeLabelEdit(object source,
NodeLabelEditEventArgs e)
{
e.CancelEdit = true;
}
}
Note that in this case, no error is generated to the user. The label is read-only.
Cancel events are not appropriate in cases where the developer would cancel the operation and return an exception. In these cases, you should raise an exception inside of the event handler in order to cancel. For example, the user might want to write validation logic in an edit control as shown.
[Visual Basic]
Public Class Form1
Inherits Form
Private edit1 As EditBox = New EditBox()

Sub TextChanging(source As Object, e As EventArgs)
Throw New RuntimeException("Invalid edit")
End Sub
End Class
[C#]
public class Form1: Form
{
EditBox edit1 = new EditBox();

void TextChanging(object source, EventArgs e)
{
throw new RuntimeException("Invalid edit");
}
Back to top Go down
https://knowledgeshare.forumotion.com
 
Coding Conventions in .net
Back to top 
Page 1 of 1
 Similar topics
-
» Coding Conventions in .net
» Coding Conventions in .net
» Coding Conventions in .net
» Coding Conventions in .net
» Coding Conventions in .net

Permissions in this forum:You cannot reply to topics in this forum
Knowledge Share :: .Net-
Jump to: