1. Common code smells include poor naming conventions, inconsistent naming, and long parameter lists. Names should be meaningful and reveal intention. Refactoring tools can help fix these issues. 2. Method signatures should be clear from the return type, name, and parameters. Avoid ambiguous signatures and magic values. 3. Nested conditional logic and duplicated code are difficult to read and maintain. Simplify conditions when possible and extract duplicated logic into reusable methods or classes.

1. Clean Code C# - Summary by Esperansa Ohad
1. Common Code Smells:
Poor Names:
• Names that are mysterious: SqlDataReader dr1; // What does dr1 mean?
int od;
void Button1_Click();
class Page1 {}
// The problem is that I need to search on another place to
understand the meaning of Button_Click() method & Page1
class.
• Possible names: SqlDataReader dataReader // or just - reader;
overdueDays
checkAvailability_Click()
ViewCustomerPage {}
Meaningless Names:
• void BeginCheckFunctionality_StoreClientSideCheckboxIDsArray();
// What does this method do? I need to see implementation to understand.
// Generally, when my function is more than 10 lines of code, it does more than one
thing.
Names with Encodings:
• Hungarian notation: int iMaxRequests; // No need to use the “i” because by hovering the
// mouse on the variable in Visual Studio, we can
// get the data type.
var m_objCollection = new StringCollection(); // What does
// objCollection mean? I need to go and see
// what is stored in that collection.
// This collection is actual a string collection
// and not objects collection.
// I can’t tell what inside that string collection.
Ambiguous Names:
• bool MultiSelect() {} // Is this method tells me that multiple items are selected or to select
// multiple items? I have again to look at the implementation.
Noisy Names:
• Customer theCustomer; // Fix to customer;
• List<Customer> listOfApprovedCustomers; // Fix to approvedCustomers;

2. Fix Code Smells:
On this topic will see how to use the “Resharper” tool to fix code smells.
• Change method names using Rename-Refactoring dialog box of resharper (Ctrl+R+R / F2).
• Change parameter names using same keys.
• Change local names using same keys – Resharper will suggest us optional names.
Names – Summary:
• Not too short, not too long.
• Meaningful.
• Reveal intention.
• Chosen from problem domain.
2. Inconsistent Naming Conventions:
Examples:
• Customer GetCustomer(int _id);
• Customer saveCustomer(Customer Customer);
• private int customerId;
In .NET Framework we have two naming conventions:
PascalCase – Class names, properties names, method names.
camelCase – Class members (variables: _id) names, method parameters names, local variables names.
We can use the Resharper Rename-Refactoring dialog to change the names as we should.
3. Poor Method Signatures:
Orange GetCustomer(int airplane); // Not an airplane object → it’s integer.
// This method returns an Orange instead of a Customer.
void Parse (int command); // Parse meaning to get a string and converting that to a different
// object.
➔ int Parse (string command);
• Typically, not always, Boolean flags in method are code smells, because this mean that the
method do two different things.
Ctrl+W on Visual Studio will extend the selection.
Ctrl+Shift+R on Visual Studio will give us the Refactor This item.
Shift+F12 on Visual Studio to find usages.
Ctrl+Shift+R on parameter name to perform safe delete.

3. Summary:
• Check the return type.
• Check the method name.
• Check the parameters.
4. Long Parameters List
This is kind of a code smell.
• CheckNotifications(null, 1, true, false, DateTime.Now);
// What each parameter represents? We need to check the implementation to know.
// On each call we need to pass a lot of arguments. Hard to understand and to use.
How to handle long parameters list?
• Identify the parameters that repeat themselves on some methods and encapsulate them inside
another class. Pass an instance of that class instead of the previous identified parameters.
• We can use the “Extract Class From Parameters” of the Resharper-Refactoring (hover the
method name and click Ctrl+Shift+R).
Summary:
• Less than 3 parameters.
5. Output Parameters:
• We shall avoid this.
• The problem is that in order to use a method with output parameter, I need to declare and
initialize the variables, and then pass it to the method.
• Use resharper refactoring to help → hover the output parameter → Ctrl+Shift+R → Transform
Out Parameters → Resharper will suggest a returned value instead (Tuple).
• Tuples are also a code smell – because item1 & item2 are not revealing the intention.
• To get rid of the Tuple we need to create a class with variables item1 & item2.
• Now to replace the usage of the Tuple on the method above with the class that we’ve created:
we put the cursor on the method name, and press Ctrl+Shift+R → Change the signature /
Ctrl+F6.
• Afterwards we can Refactor-Rename the names of item1 & item2 on the new class, and
manually change returned values if necessary.
• If we have an argument that is a magic value – we can use Resharper’s Ctrl+Shift+R → Introduce
Variable to assign it into a variable. Instead we can use the named parameters of C# in order to
be more intention revealing.

4. 6. Variable Declarations on the Top:
• In old days it was common to declare variables on top of the methods.
• Now days we should declare the variables where we need them.
• The reason – to keep the context reasonable.
• If an initialization to a variable is grayed out it’s mean that the initialization is unnecessary.
• Resharper’s Ctrl+Shif+R → Inline the variable → Will not work because of the initialization.
• Alt+Enter to display the menu of the yellow bulb → remove redundant initializer.
• If the declaration is green underlined so we click Alt+Enter again and select join declaration and
assignment.
• If we have an initialization that must to stay, we need to move the declaration close to the
usage manually.
Variables - Summary:
• Declare them close to their usage.
7. Magic Numbers:
• Avoid magic numbers.
• Mark the magic number → Resharper-Refactoring by Ctrl+Shift+R and select one of the
following options:
o Introduce Field
o Introduce Parameter
o Introduce Variables
• When we use proper name – we don’t need to use comments. The code is readable.
• We can introduce constant instead – when we need to use the value in some places along the
code: Ctrl+Shift+R → Introduce Field → Give a proper name and select “Introduce constant”.
• We can convert multiple constants to an enumeration by: Mark all constants declarations →
Ctrl+Shift+R → Extract Class → On Extract class field we give the name of the class
(remember that for naming enumerable in .NET we use a singular form) → Keep to make
the fields public so they can be accessible outside the class → Resharper will put the
declaration on another file → manually convert class to enum.
• Maybe we need to change afterwards the signature of the method (for example if we compare
now the new enum with an int parameter): safe way is to use change-signature-refactoring →
we put the cursor on the method name → Ctrl+F6 or Ctrl+Shift+R and select Change signature.
Avoid Magic Numbers – Summary:
• Use constants or enums.
8. Nested Conditionals:
If…if…else….
• Code smell.
• Programs are hard to read, hard to change, hard to understand and hard to test.
• The more nested conditions we have, the more execution pass that we have.
• if… else… → if a ? 1 : 2;

5. Ternary Operator Abuse:
c = a ? b : d ? e : f;
• Such expression unmaintainable.
• Do not apply more than one in expression.
Simplify true/false:
if (a)
b = true;
else
b = true;
➔ b = a;
Combine:
if (a)
{
if (b)
{
Statement
}
}
➔ Combine:
if (a && b)
{
statement
}
➔ Early Exit – we can use the Guard statements:
if (!a)
return;
if (!b)
return;
statement

6. ➔ Early Exit + Combine:
if (!a || !b)
return;
statement
Everything in moderation!
if (a && (b || c) && !d || e && (f && !g || h)
STINKS!!!
• Can’t read or understand an expression like that.
• Recommended to ask someone else for their opinion about our code.
• Rule – write clean code for others, not for ourselves!!!
In Visual Studio we need to do the hard work – there are no shortcuts for refactoring the nested if.
9. Switch Case statements:
• If possible – convert switch statements to more polymorphic classes.
• One parent class and sub-classes which replace the cases on the switch statements.
• The more an object is used in our method → the more the method is needed to be placed in this
object.
• Encapsulation principle say: we want to have data and methods where operations works on the
data on the same class.
• Ctrl+shift+R (hammer) on the method name → move instance method.
• Alt+Enter (yellow/red bulb) on unrecognized variable to declare it somewhere (locally/globally).
• Recommended to use TDD = Test Driven Development in order to refactor our project.
• To push down functionality from parent to its sons, we need to put the mouse cursor on the
method name → Ctrl+Shift+Alt + up/down → Push Members Down.
Switch Statements – Summary
• Replace them with polymorphic dispatch.
• Use Push Member Down refactoring.
10. Duplicated Code:
• DRY – Don’t Repeat Yourself.
• A change is needed to be made in several places.
11. Comments:
• Comments are code smells in most cases.
• The code should be readable enough without comments.
• Don’t write comments. Re-write your code!
• Don’t explain “whats” (the obvious).
• Explain “whys” and “hows”.

7. 12. Long Methods:
• Long method is one that is more than 10 lines of code.
Problems with Long Methods:
• Hard to understand.
• Hard to change.
• Hard to re-use.
• We want methods that specialize in one thing.
Cohesion Principle:
• Things that are related, should be together.
• Things that are not related, should not be together.
Single Responsibility Principle:
• A class / method should do only one thing and do it very well.
Methods Best Practices:
• Should be short (less than 10 lines).
• Should do only one thing.
Order in class:
• Fields & Properties.
• Public methods.
• Protected methods.
• Private methods.