DotNet First Side: Apr 17, 2008

1 Capitalization Styles

Pascal Casing

This convention capitalizes the first character of each word (as in SumSal).

Camel Casing

This convention capitalizes the first character of each word except the first character of the first word. E.g. sumSal.

3 Guidelines

3.1 Naming Conventions and Style

1. Use Pascal casing for type and method names

public class SomeClass

{

public SomeMethod(){}

}

Class names must be Nouns or Noun phrases.

Name methods with Verbs or Verb phrases.

2. Use camel casing for local variable names and method arguments

int number; someNumber

void MyMethod(int someNumber)

{

}

Try to avoid abbreviations in method arguments.

3. Name interfaces with I prefix

interface IMyInterface

{ .. }

Use Pascal Casing

Page 5 of 21

start the interface name with "I" and capitalize the letter following the "I"

4. Prefix private member variables with m_

public class SomeClass

{

private int m_Number;

}

Microsoft recommends against the m_ (and the straight _) even though they did both in their code.

Use camel case.

Ex: private int _someNumber

5. Suffix custom attributes classes with Attribute.

Follow class naming conventions, but add Attribute to the end of the name

Ex: SomeNumberAttribute

6. Suffix custom exception classes with Exception.

Follow class naming conventions, but add Exception to the end of the name

Ex: SomeNumberException

7. Name methods using verb-object pair, such as ShowDialog ()
8. Methods with return values should have a name describing the value returned, such

as GetObjectState().

9. Use descriptive variable names. Avoid one-character variable names, such as i or t. Use index or temp instead.

Counting variables are preferably called i, j, k, l, m, n when used in 'trivial'

counting loops, but try using meaningful names for variables used as counters

E.g. EmpCount

Use Pascal Casing.

10. All member variables should be declared at the top, with one line separating them

from the properties or methods

public class MyClass

{

int m_Number;

string m_Name;

public void SomeMethod1(){}

public void SomeMethod2(){}

Page 6 of 21

}

11. Declare a local variable as close as possible to its first use.

12. Use meaningful namespaces such as the product name, company name, etc.

Namespace names must be nouns or noun phrases.

Use Pascal Casing no underscores.

Use CompanyName.TechnologyName as root. If you don't have

a company, use your domain name or your own initials. Note that any acronyms of

three or more letters should be pascal case (Xml instead of XML) instead of all caps

Ex:.DotNetTraining.Xml

Use hierarchical names for namespaces with dots as separation points for namespaces that are related and can be grouped together. For example consider the following:

Database - Main namespace

Database.Records - Records namespace

Database.Tables - Table functions namespace

13. Avoid fully qualified type names. Use the using statement instead.
14. Avoid putting a using statement inside a namespace.
15. Group all framework namespaces together and put custom or third party namespaces beneath.

using System;

using System. Collections;

using System.ComponentModel;

using System.Data;

using MyCompany;

using MyControls;

16. A file name should reflect the class it contains.
17. Always place an open curly brace ({) in a new line.
18. With anonymous methods mimic the code layout of a regular method, aligned with the anonymous delegate declaration.

Follow class naming conventions, but add Delegate to the end of the name

a. Comply with placing an open curly brace in a new line

delegate void SomeDelegate(string str);

//Correct:

public void InvokeMethod()

Page 7 of 21

{

SomeDelegate del = delegate(string str)

{

MessageBox.Show(str);

}

del("Hello");

}

//Avoid

public void InvokeMethod()

{

SomeDelegate del = delegate(string str){MessageBox.Show(str);};

del("Hello");

}

Varaible/Paramater Type Prefix

Basic Type	Prefix
sbyte (System.Sbyte)	sbyt
byte (System.Byte)	byt
char (System.Char)	chr
short (System.Int16)	sh
ushort (System.UInt16)	ush
bool (System.Boolean)	b
int (System.Int32)	n
uint (System.UInt32)	un
long (System.Int64)	l
ulong (System.UInt64)	ul
decimal (System.Decimal)	dc
double (System.Double)	d
float (System.Single)	f
string (System.String)	s
DateTime	dt
TimeSpan	ts
object (System.Object)	o

3.2 Comments and Embedded Documentation
1. 1. Each file shall contain a header block.

The header block must consist of a #region block containing the following copyright statement and the name of the file.

2. Use // for comments.

Page 8 of 21

3. Do not use blocks of //-------- or //********.
4. All comments shall be written in English.
5. Use XML tags for documenting types and members.

All public and protected types, methods, fields, events, delegates, etc. shall be documented using XML tags. Using these tags will allow IntelliSense to provide useful details while using the types. Also, automatic documentation generation tooling relies on these tags.

Section tags define the different sections within the type documentation.

Section Tags	Description	Location
<summary>	Short description	type or member
<remarks>	Describes preconditions and other additional information.	type or member
<param>	Describes the parameters of a method	method
<returns>	Describes the return value of a method	method
<exception>	Lists the exceptions that a method or property can throw	method, even or property
<value>	Describes the type of the data a property accepts and/or returns	property
<example>	Contains examples (code or text) related to a member or a type	type or member
<seealso>	Adds an entry to the See Also section	type or member
<overloads>	Provides a summary for multiple overloads of a method	first method in a overload list.

SECTION TAGS DESCRIPTION LOCATION

Inline tags can be used within the section tags.

Inline Tags	Description
<see>	Creates a hyperlink to another member or type
<paramref>	Creates a checked reference to a parameter

Markup tags are used to apply special formatting to a part of a section. Page 9 of 21

Markup Tags	Description
<code>	Changes the indentation policy for code examples
<c>	Changes the font to a fixed-wide font (often used with the <code> tag)
<para>	Creates a new paragraph
<list>	Creates a bulleted list, numbered list, or a table.
<b>	Bold typeface
<i>	Italics typeface

Exception:

In an inheritance hierarchy, do not repeat the documentation but use the <see> tag to refer to the base class or interface member.

6. Use #region to group non-public members.

If a class contains a large number of members, attributes, and/or properties, put all non-public members in a region. Preferably, use separate regions to split-up the private, protected, and internal members, and a region to hide all fields. It is also allowed to use the #region construct for separating the smaller auxiliary classes from the main class.

Page 10 of 21

3.3 Coding Practices
1. 1. Always use C# predefined types rather than the aliases in the System namespace.

For example:

object NOT Object

string NOT String

int NOT Int32

2. Avoid putting multiple classes in a single file.

3. A single file should only contribute types to a single namespace. Avoid having multiple namespaces in the same file.

4. Avoid files with more than 500 lines (excluding machine-generated code).

5. Lines should not exceed 80 characters.

6. Do not manually edit any machine-generated code.

7. If modifying machine-generated code, modify the format and style to match this

coding standard.

8. Avoid comments that explain the obvious.

9. Document only operational assumptions, algorithm insights etc.

10. Never hard-code a numeric value, always declare a constant instead.

11. Make only the most necessary types public, mark others as internal.

12. Always use zero-based arrays.

13. Avoid specifying a type for an enum (like long).

14. Never use goto unless in a switch statement fall-through.

15. Avoid function calls in Boolean conditional statements. Assign into local variables and check on them:

bool IsEverythingOK()

{…}

//Avoid:

if(IsEverythingOK())

{…}

//Instead:

bool ok = IsEverythingOK();

if(ok)

{…}

16. Only catch exceptions for which you have explicit handling.

Page 11 of 21

17. Avoid error code as methods return values.
18. Do not use the new inheritance qualifier. Use override instead.
19. Minimize code in application assemblies (EXE client assemblies), use class libraries instead to contain business logic.
20. Never hardcode strings that will be presented to end-users. Use resources instead.
21. Never hardcode strings that might change based on deployment such as connection strings.
22. Never use unsafe code unless when using interop.
23. Avoid multiple Main() methods in a single assembly.
24. Never assume a type supports an interface. Defensively query for that interface.

SomeType obj1;

IMyInterface obj2;

/* Some code to initialize obj1, then: */

obj2 = obj1 as IMyInterface;

if(obj2 != null)

{

obj2.Method1();

}

else

{

//Handle error in expected interface

}

25. Do not provide public or protected member variables. Use properties instead.

26. Do not provide public event member variables. Use event assessors instead.

public class MySource

{

MyDelegate m_NumberChangedEvent;

public event MyDelegate NumberChangedEvent

{

add

{

m_NumberChangedEvent + = value;

}

remove

{

m_NumberChangedEvent - = value;

}

Page 12 of 21

27. Avoid events as interface members.
28. Avoid abstract methods, use interfaces instead.
29. Always mark public and protected methods as virtual in a non-sealed class.
30. When building a long string, use StringBuilder, not string.
31. Always use a curly brace scope in an if statement, even if it conditions a single statement.
32. Always provide a static constructor when providing static member variables.
33. Avoid code that relies on an assembly running from a particular location.
34. Do not use late-binding invocation when early-binding is possible.
35. Avoid using the trinary conditional operator.
36. Use the EventsHelper class to publish events defensively.
37. Use application logging and tracing.
38. Do not use the base word to access base class members unless you wish to resolve a conflict with a subclasses member of the same name or when invoking a base class Constructor.

4 Object Lifecycle
1. 1. Declare and initialize variables close to where they are used.
2. 2. If possible, initialize variables at the point of declaration.

If you use field initialization then instance fields will be initialized before the instance constructor is called. Likewise, static fields are initialized when the static constructor is called. Notice that the compiler will always initialize any uninitialized reference variable to zero.

3. Declare each variable in a separate declaration statement.

4. Use a const field to define constant values.

Making it const ensures that memory is allocated for that item only once.

private const int maxUsers = 100;

Exception

If the value of a constant field must be calculated at run-time (in the static constructor), use a static read only field instead.

5. Set a reference field to null to tell the Garbage Collector that the object is no longer needed.

Setting reference fields to null may improve memory usage because the object involved will be unreferenced from that point on, allowing the Garbage Collector

Page 13 of 21

to clean-up the object much earlier. Please note that this recommendation should not be followed for a variable that is about to go out of scope.

6. Avoid implementing a destructor.

The use of destructors in C# is demoted since it introduces a severe performance penalty due to way the Garbage Collector works. It is also a bad design pattern to clean up any resources in the destructor since you cannot predict a which time the destructor is called (in other words, it is non-deterministic).

Notice that C# destructors are not really destructors as in C++. They are just a C# compiler feature to represent CLR Finalizers.

7. If a destructor is needed, also use GC.SuppressFinalize.

If a destructor is needed to verify that a user has called certain cleanup methods such as Close() on a IpcPeer object, call GC.SuppressFinalize in the Close() method. This ensures that the destructor is ignored if the user is properly using the class.

8. Implement IDisposable if a class uses unmanaged or expensive resources.

If a class uses unmanaged resources such as objects returned by C/C++ DLLs, or expensive resources that must be disposed of as soon as possible, you must implement the IDisposable interface to allow class users to explicitly release such resources.

9. Do not access any reference type members in the destructor.

When the destructor is called by the Garbage Collector, it is very possible that some or all of the objects referenced by class members are already garbage collected, so dereferencing those objects may cause exceptions to be thrown. Only value type members can be accessed (since they live on the stack).

4.1 Control Flow
1. 1. Do not change a loop variable inside a for loop block.

Updating the loop variable within the loop body is generally considered confusing, even more so if the loop variable is modified in more than one place.

2. Update loop variables close to where the loop condition is specified.

This makes understanding the loop much easier.

All flow control primitives (if, else, while, for, do, switch) shall be followed by a block, even if it is empty.

Please note that this also avoids possible confusion in statements of the form:

if (b1) if (b2) Foo(); else Bar(); // which ‘if’ goes with the ‘else’?

3. All switch statements shall have a default label as the last case label.

Page 14 of 21

A comment such as “no action” is recommended where this is the explicit intention. If the default case should be unreachable, an assertion to this effect is recommended.

4. Avoid multiple or conditional return statements.

One entry, one exit is a sound principle and keeps control flow simple. However, if some cases, such as when preconditions are checked, it may be good practice to exit a method immediately when a certain precondition is not met.

5. Do not make explicit comparisons to true or false.

It is usually bad style to compare a bool-type expression to true or false.

Example:

while (condition == false) // wrong; bad style

while (condition != true) // also wrong

while (booleanCondition) // OK

6. Do not access a modified object more than once in an expression.

The evaluation order of sub-expressions within an expression is defined in C#, in contrast to C or C++, but such code is hard to understand.

Example:

v[i] = ++c; // right

v[i] = ++i; // wrong: is v[i] or v[++i] being assigned to?

i = i + 1; // right

i = ++i + 1; // wrong and useless; i += 2 would be clearer

7. Do not use selection statements (if, switch) instead of a simple assignment or initialization.

Express your intentions directly. For example, rather than

bool pos;

if (val > 0)

{

pos = true;

}

else

{

pos = false;

}

or (slightly better)

bool pos = (val > 0) ? true : false;

write

Page 15 of 21

bool pos;

pos = (val > 0); // single assignment

or even better

bool pos = (val > 0); // initialization

4.2 Object Oriented Programming
1. 1. Declare all fields (data members) private.
2. 2. Explicitly define a protected constructor on an abstract base class.
3. 3. Selection statements (if-else and switch) should be used when the control flow depends on an object’s value; dynamic binding should be used when the control flow depends on the object’s type. This is a general OO principle. Please note that it is usually a design error to write a selection statement that queries the type of an object (keywords typeof, is).

Exception:

Using a selection statement to determine if some object implements one or more optional interfaces is a valid construct though.

4. All variants of an overloaded method shall be used for the same purpose and have similar behavior.

4.3 Use C# to describe pre-conditions post-conditions, exceptions, and class invariants.
1. 1. It shall be possible to use a reference to an object of a derived class wherever a reference to that object’s base class object is used.
2. 2. Do not modify the value of any of the operands in the implementation of an overloaded operator.
3. 3. Use a struct when value semantics are desired. More precisely, a struct should be considered for types that meet any of the following criteria:
4. � Act like primitive types.
5. � Have an instance size fewer than .16 bytes.
6. � Are immutable.
7. � Value semantics are desirable.
8. � Remember that a struct cannot be derived from.
9. 4. Allow properties to be set in any order.

Properties should be stateless with respect to other properties, i.e. there should not be an observable difference between first setting property A and then B and its reverse.

Page 16 of 21

5. Use a property rather than a method when the member is a logical data member.
6. Use a method rather than a property when this is more appropriate.

In some cases a method is better than a property:

� 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 observable side effect.
� Calling the member twice in succession produces different results.
� The order of execution is important
� The member is static but returns a value that can be changed.
� The member returns a copy of an internal array or other reference type.
� Only a set accessor would be supplied. Write-only properties tend to be confusing.
7. Do not create a constructor that does not yield a fully initialized object.
8. Always check the result of an as operation.

If you use as to obtain a certain interface reference from an object, always ensure that this operation does not return null. Failure to do so may cause a NullReferenceException at a later stage if the object did not implement that interface.

4.4 Exceptions

Name exceptions with the “Exception” suffix.

Use Pascal Casing

Consider naming exceptions using nouns or noun phrases

1. Only throw exceptions in exceptional situations.

Do not throw exceptions in situations that are normal or expected (e.g. end-of-file). Use return values or status enumerations instead. In general, try to design classes that do not throw exceptions in the normal flow of control. However, do throw exceptions that a user is not allowed to catch when a situation occurs that may indicate a design error in the way your class is used.

2. Do not throw exceptions from inside destructors.

When you call an exception from inside a destructor, the CLR will stop executing the destructor, and pass the exception to the base class destructor (if any). If there is no base class, then the destructor is discarded.

3. Only re-throw exceptions when you want to specialize the exception.

Page 17 of 21

Only catch and re-throw exceptions if you want to add additional information and/or change the type of the exception into a more specific exception. In the latter case, set the InnerException property of the new exception to the caught exception.

4. List the explicit exceptions a method or property can throw.

Describe the recoverable exceptions using the <exception> tag.

Explicit exceptions are the ones that a method or property explicitly throws from its implementation and which users are allowed to catch. Exceptions thrown by .NET framework classes and methods used by this implementation do not have to be listed here.

5. Always log that an exception is thrown.

Logging ensures that if the caller catches your exception and discards it, traces of this exception can be recovered at a later stage.

6. Allow callers to prevent exceptions by providing a method or property that returns the object’s state.

For example, consider a communication layer that will throw an InvalidOperationException when an attempt is made to call Send () when no connection is available. To allow preventing such a situation, provide a property such as Connected to allow the caller to determine if a connection is available before attempting an operation.

7. Use standard exceptions.

8. Throw informational exceptions.

When you instantiate a new exception, set its Message property to a descriptive message that will help the caller to diagnose the problem

9. Throw the most specific exception possible.

10. Do not throw an exception from inside an exception constructor.

Throwing an exception from inside an exception’s constructor will stop the construction of the exception being built, and hence, preventing the exception from getting thrown. The other exception is thrown, but this can be confusing to the user of the class or method concerned.

4.5 Delegates & Events
1. 1. Do not make assumptions on the object’s state after raising an event.

Prepare for any changes to the current object’s state while executing an event handler. The event handler may have called other methods or properties that changed the object’s state (e.g. it may have disposed objects referenced through a field).

Page 18 of 21

2. Raise events through a protected virtual method.

If a derived class wants to intercept an event, it can override such a virtual method, do its own work, and then decide whether or not to call the base class version. Since the derived class may decide not to call the base class method, ensure that it does not do any work required for the base class to function properly. Name this method OnEventName, where EventName should be replaced with the name of the event.

3. Use the sender/arguments signature for event handlers.

The goal of this recommendation is to have a consistent signature for all event handlers. In general, the event handler’s signature should look like this public delegate void MyEventHandler(object sender, EventArgs arguments)

Using the base class as the sender type allows derived classes to reuse the same event handler. The same applies to the arguments parameter. It is recommended to derive from the .NET Framework’ s EventArgs class and add your own event data. Using such a class prevents cluttering the event handler’ signature, allows extending the event data without breaking any existing users, and can accommodate multiple return values (instead of using reference fields). Moreover, all event data should be exposed through properties, because that allows for verification and preventing access to data that is not always valid in all occurrences of a certain event.

4. Implement add/remove accessors if the number of handlers for an event must be limited.

If you implement the add and remove accessors of an event, then the CLR will call those accessors when an event handler is added or removed. This allows limiting the number of allowed event handlers, or to check for certain preconditions.

Consider providing property-changed events.

Consider providing events that are raised when certain properties are changed. Such an event should be named

PropertyChanged, where Property should be replaced with the name of the property with which this event is associated.

5. Consider an interface instead of a delegate.

If you provide a method as the target for a delegate, the compiler will only ensure that the method signature matches the delegate’s signature.

This means that if you have two classes providing a delegate with the same signature and the same name, and each class has a method as a target for that delegate, it is possible to provide the method of the first class as a target for the

Page 19 of 21

delegate in the other class, even though they might not be related at all. Therefore, it is sometimes better to use interfaces. The compiler will ensure that you cannot accidentally provide a class implementing a certain interface to a method that accepts another interface that happens to have the same name.

5 Framework Specific Guidelines
5.1 Data Access
1. 1. Always use type-safe data sets. Avoid raw ADO.NET.
2. 2. Always use transactions when accessing a database.
3. 3. Always use transaction isolation level set to Serializable.
4. a. Requires management decision to use anything else.
5. 4. Do not use the Server Explorer to drop connections on windows forms, ASP.NET forms or web services. Doing so couples the presentation tier to the data tier.
6. 5. Avoid SQL Server authentication.
7. a. Use Windows authentication instead.
8. 6. Run components accessing SQL Server under separate identity from that of the calling client.
9. 7. Always warp your stored procedures in a high level, type safe class. Only that class invokes the stored procedures.
10. 8. Avoid putting any logic inside a stored procedure.
11. a. If there is an IF inside a stored procedure, you are doing something wrong.
5.2 ASP.NET and Web Services
1. 1. Avoid putting code in ASPX files of ASP.NET. All code should be in the code behind class.
2. 2. Code in code behind class of ASP.NET should call other components rather than contain direct business logic.
3. 3. In both ASP.NET pages and web services, wrap a session variables in a local property. Only that property is allowed to access the session variable, and the rest of the code uses the property, not the session variable.
4. 4. In transactional pages or web services, always store session in SQL server.
5. 5. Strive to provide interfaces for web services
6. 6. Always provide namespace and service description for web services.
7. 7. Always provide a description for web methods.

Page 20 of 21

8. When adding a web service reference, provide meaningful name for the location.
9. Always modify client-side web service wrapper class to support cookies.
a. You have no way of knowing whether the service uses Session state or not.

5.3 Serialization
1. 1. Always mark non-sealed classes as Serializable.
2. 2. Always mark un-serializable member variables as non serializable.
3. 3. Always mark delegates on a serialized class as non-serializable fields:

[Serializable]

public class MyClass

{

[field:NonSerialized]

public event MyDelegate Delegate;

}

5.4 Remoting
1. 1. Prefer administrative configuration to programmatic configuration.
2. 2. Always implement IDisposable on a single call objects.
3. 3. Always prefer TCP channel and binary format when using remoting.
4. a. Unless a firewall is present.
5. 4. Always provide a null lease for a singleton object.

public class MySingleton : MarshalByRefObject

{

public override object InitializeLifetimeService()

{

return null;

}

5. Always provide a sponsor for a client-activated object. Sponsor should return initial lease timed.

6. Always unregistered a sponsor on client application shutdown.

7. Always put remote objects in class libraries.

8. Avoid using SoapSuds.

9. Avoid hosting in IIS.

10. Avoid using uni-directional channels.

Page 21 of 21

11. Always elevate type filtering to full on both client and host to allow callbacks.

Host Config file:

</serverProviders>

</channel>

</serverProviders>

</channel>

</channels>

Client Config file:

</serverProviders>

</channel>

</channels>

Software Engineer

Google's software engineers develop the next-generation technologies for which the compay has become world-renowned. Projects include working on advanced information-retrieval algorithms, massive scalability and storage solutions, and large-scale applications that enrich the user experience. Examples of Gmail software engineer projects include: the storage system that holds, searches and serves petabytes of email data, the machine learning and classification systems that keep spam out of inboxes, high-speed and robust mail delivery systems, our POP and IMAP servers that let users read their mail from any client or devices, and more. Many of our software engineers who are interested in working in Java/Javascript, and on user-facing parts of the product, work on projects described in the User Interface Software Engineer description below.

Requirements

BS or MS in Computer Science or equivalent (Ph.D. a plus).
Several years of software development experience.
Extensive experience programming in C++.
Extensive knowledge of Unix/Linux or Windows environments.
Knowledge of TCP/IP and network programming.
Experience developing/designing large software systems.
Experience programming in Python a plus.

This position is available in any one of the Gmail offices -- Mountain View, Seattle or Zurich. If you are interested in working from another Google office, you may still apply below. You'll interview with a wide range of Google engineers, not just Gmail engineers, and be eligible for a position on any team at Google.

To apply, submit your resume and info:

User Interface Software Engineer

You will specialize in building responsive and elegant web UIs with AJAX and similar technologies. Some examples of Gmail UI engineering projects: Gmail chat, the Gmail iPhone interface, conversation view (a.k.a. threaded emails), custom "From" addresses, high precision user-perceived performance analysis &optimization, complete AJAX architecture redesigns to make the codebase modular and highly extensible -- basically, all the parts of Gmail that you see when you sign in.

Requirements

4+ years JavaScript/HTML/CSS ("AJAX") experience
Significant development experience in C/C++ or Java
Experience with server-side web frameworks such as JSP or ASP.Net
Expert HTML, JavaScript, and CSS Skills
Deep experience designing modular, object-oriented JavaScript
User Interface design knowledge a plus
Experience with UI frameworks such as XUL, Flex, and XAML a plus

This position is available in Mountain View or Zurich. If you are interested in working from another Google office, you may still apply below. You'll interview with a wide range of Google engineers, not just Gmail engineers, and be eligible for a position on any team at Google.

To apply, submit your resume and info:

DotNet First Side

Thursday, April 17, 2008

What is the difference between Class and structure’s ?

Difference between localization and globalization

Namespaces during localization and globalization

Using Repeater inside a Repeater.

Coding Guidelines for C# .NET

Jobs In GOOGLE

Software Engineer

User Interface Software Engineer

What is BitArray ?

What is lock statement in C#?

what is the control for which by default post back is enabled(true)

What are similarities between Class and structure ?

Dotnet-Interviews

Blog Archive

Blog Roll