This is the presentation I gave at Sela on 29/10/2018. It covers some best practices for writing clean code and for doing refactoring efficiently. It also describes some of Resharper's features for refactoring and code analysis.
6. Clean Code
• Readability
– Naming
– Formatting
• Method length
• Number of parameters
• Modularity and Reusability
– Law of Demeter
– Avoid static and Singletons
• Exception Handling
7. Law of Demeter
Method f in class C should only call methods of:
C
An object created by f
An object passed as an argument to f
An object held by an instance variable of C
Counter example:
string outputDir =
ctxt.getOptions().getScratchDir().getAbsolutePath();
8. The SOLID principles
• Single Responsibility
• Open/Close
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
9. 4 Rules of Simple Design / Kent Beck
• Passes all the tests
• Reveals the intent
• No duplication (DRY)
• Fewest elements (YAGNI)
(order matters)
11. Poka Yoke - examples
• private/public
• readonly fields and get-only properties
• Use classes instead of strings and integers
• Use most specific interfaces
– E.g. IReadOnlyCollection<T> instead of List<T>
14. Refactoring – Best Practices
• Small Steps
• Test Often
• Write missing unit-tests
• Pair-programming
• Add before remove
• Use TODO and [Obsolete] midway
15. Add Before Remove
public class SomeClass
{
public SomeClass()
{
//...
}
public void Foo(int someParam)
{
// use someParam...
}
}
Initial state
16. Add Before Remove
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo()
{
// use _someParam...
}
}
Final (desired)
state
17. Add Before Remove
public class SomeClass
{
public SomeClass()
{
//...
}
public void Foo(int someParam)
{
// use someParam...
}
}
Initial state
18. Add Before Remove
public class SomeClass
{
public SomeClass()
{
//...
}
private int _someParam;
public SomeClass(int someParam) : this()
{
_someParam = someParam;
}
public void Foo(int someParam)
{
//use someParam...
}
}
Step1 – Add
constructor
overload
19. Add Before Remove
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo(int someParam)
{
//use someParam...
}
}
Step2 – Remove old
constructor overload
20. Add Before Remove
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo(int someParam)
{
//use someParam...
}
public void Foo()
{
Foo(_someParam);
}
}
Step3 – Add
new overload
of Foo
21. Add Before Remove
public class SomeClass
{
private int _someParam;
public SomeClass(int someParam)
{
//...
_someParam = someParam;
}
public void Foo()
{
//use _someParam...
}
}
Step4 (final) –
Remove old
overload of Foo
36. Summary
• Clean code is essential for productivity
and quality
• Refactoring is essential to keep clean
code
• It’s important to learn and practice
Clean Code and Refactoring
• Mastering the tools will make you
hyper-productive!
באתי מהכיוון של Clean code ו-Unit tests לתחום הבדיקות האוטומטיות. היום אני רוצה לחזור כי לדעתי שם נמצאות הבעיות האמיתיות...
The goal: to improve maintainability
It’s not:
A complete rewrite
Bug fixing
Changing a technology (to some extent)
Behavior is contextual
What are the boundaries of the refactored system?
Is “performance” considered behavior
Is CPU and memory consumption behavior?
Is Reflection should be preserved?
Exceptions (backward compatibility)
Does the bits should be preserved…?
We should know our presumptions
But really:
Amount of time spent on debugging and understanding of code
Makes it easier to prove correctness and avoid bugs
Makes it easy and safe to make changes
רשימה חלקית, ממש על קצה המזלג, של הכללים שנכללים תחת הקטגוריה של Clean code
Many of these principles rely on Polymorphism which is based on the concept of callback functions.
This is a concept that developers must master
בא לידי ביטוי בארכיטקטורה, בקוד ובתהליכי העבודה (למשל strongly typed)
להחליף תמונה
TDD provides a safety net
Caution: If tests are bad, refactoring can be more difficult than without!
On the other hand, TDD drives for good tests
Small steps, climbers rule
להחליף תמונה
TDD provides a safety net
Caution: If tests are bad, refactoring can be more difficult than without!
On the other hand, TDD drives for good tests
Small steps, climbers rule
להחליף תמונה
TDD provides a safety net
Caution: If tests are bad, refactoring can be more difficult than without!
On the other hand, TDD drives for good tests
Small steps, climbers rule
להחליף תמונה
TDD provides a safety net
Caution: If tests are bad, refactoring can be more difficult than without!
On the other hand, TDD drives for good tests
Small steps, climbers rule
להחליף תמונה
TDD provides a safety net
Caution: If tests are bad, refactoring can be more difficult than without!
On the other hand, TDD drives for good tests
Small steps, climbers rule
להחליף תמונה
TDD provides a safety net
Caution: If tests are bad, refactoring can be more difficult than without!
On the other hand, TDD drives for good tests
Small steps, climbers rule