Clean mit visual studio

SAUBERER CODE
„Clean Code“
DANK VISUAL STUDIO

Der Sprecher
Hendrik Lösch
Senior Consultant & Coach
Hendrik.Loesch@saxsys.de
@HerrLoesch
Just-About.Net

Technische Schuld
Quelle: Ron Jeffries http://xprogramming.com/articles/refactoring-not-on-the-backlog

Technische Schuld
Zeit
Produktivität

Technische Schuld
Quelle: Martin Fowler http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Ward Cunningham
rücksichtslos umsichtig
überlegt
versehentlich
„Wir haben keine
Zeit für ein
Design.“
„Wir müssen jetzt
liefern und uns später
um die Konsequenzen
kümmern.“
„Jetzt wissen wir wie
wir es hätten machen
müssen.“
„Layer? Was ist
das?“

Lesbarkeit & Code Stil
Gmäeß eneir Sutide eneir elgnihcesn Uvinisterät ist es nchit witihcg, (…)
Gmäes enia Shutidce ebneir älgnihcesn Uveinihnstert ißt es nchit whcitich, (...)
Quelle: http://www.fehler-haft.de/wissen/buchstabensalat.html

Lesbarkeit & Code Stil
Quelle: Johannes Hofmeister, http://empathic.herokuapp.com

StyleCop
Statische Analyse von Code mit Einbindung
in den Build
Adressiert:
• Dokumentation
• Layout
• Wartbarkeit
• Namensgebung
• Lesbarkeit
Basiert auf den Framework Design Guidelines von Microsoft

private string name;
public string Name
{
get
{
return this.name;
}
set
{
this.name = value;
}
}
private string m_name;
public string Name
{
get { return m_name; }
set { m_name = value; }
}
Religionskriege
var name = "Hendrik";
string name = "Hendrik";

StyleCop
Legacy Software Visual Studio Projekttemplate

StyleCop vs. Ghost Doc & Resharper

FX Cop
Statische Analyse von kompiliertem Code mit Einbindung in den
Build
Adressiert:
• Performance
• Sicherheit
• Namensgebung
• Interoperabilität
• …

Lines of Code
SLOC
(in Mio.)
Windows NT 3.1 (1993) 4–5
Windows NT 3.5 (1994) 7–8
Windows NT 4.0 (1996) 11–12
Windows 2000 (2000) > 29
Windows XP (2001) 40
Windows Server 2003 (2003) 50

Lines of Code
= 187 LoC
π •👍
Klasse < 500LoC
Methode < 50LoC ?

Class Coupling
1 2 3
π •👍
Methode <= 9
???

Class Coupling
π •👍
Methode <= 9
✄???

Class Coupling
π •👍
Methode <= 9
???

Depth of Inheritance
π •👍
Hierachieebene <= 6
Favour Composition over Inheritance!!!
public class ActionBarViewModel : ReactiveObject, IActionBarViewModel

Depth of Inheritance
π •👍
Hierachieebene <= 6
✓ Information Hiding Principle
✓ Interface Segregation Principle

Cyclomatic Complexity
Komplexität == 2

Komplexität == 3
public SourceSelectionViewModel(IEventAggregator eventAggregator)
{
this.eventAggregator = eventAggregator;
this.readDataCommand = new ReactiveCommand();
this.readDataCommand.Subscribe( _ => this.ReadData());
}

Komplexität == 4
Komplexität == 4

π •👍
1 bis 10 = normal
11 bis 20 = moderat
21 bis 50 = riskant
> 50 = instabil

Maintainability Index
20 bis 100
9 bis 20
0 bis 9
Maintainability Index = MAX(0,(171 - 5.2 * log(Halstead Volume)
- 0.23 * (Cyclomatic Complexity)
- 16.2 * log(Lines of Code))*100 / 171)

Halstead Volume
Quelle: http://de.wikipedia.org/wiki/Halstead-Metrik

Maintainability Index
Kopplung
Methode <= 9
LoC
Klasse < 500
Methode < 50
Komplexität
1 bis 10 = normal
11 bis 20 = moderat
21 bis 50 = riskant
> 50 = instabil
?

Code Clones
*.codeclonesettings
<CodeCloneSettings>
<Exclusions>
<File>GeneratedFiles*.cs</File>
</Exclusions>
</CodeCloneSettings>

Code Coverage aka Test Coverage

Code Coverage aka Test Coverage
Komplexität == 3

C.R.A.P.
“The C.R.A.P. (Change Risk Analysis and Predictions) index is designed
to analyze and predict the amount of effort, pain, and time required to
maintain an existing body of code.”
Alberto Savoia
Quelle: http://www.artima.com/weblogs/viewpost.jsp?thread=210575
C.R.A.P.(m) = CC(m)^2 * (1 – Coverage(m)/100)^3 + CC(m)

C.R.A.P.
Quelle: https://www.artima.com/weblogs/viewpost.jsp?thread=215899
C.R.A.P.(m) = CC(m)^2 * (1 – Coverage(m)/100)^3 + CC(m)
π •👍
30
Method’s CC % of coverage required to be below CRAPpy threshold
0 – 5 0%
10 42%
15 57%
20 71%
25 80%
30 100%
31+ No amount of testing will keep methods this complex out of CRAP
territory.

Wieviel ist gut für mich?
Quelle: Dr. Elmar Jürgens, CQSE
4
3
2
1
Keine Defizite
Keine Defizite in geändertem Code
Keine neuen Defizite
Egal

Pragmatismus vs. Overengineering
Pragmatismus Overengineering

Code Contracts
public double Divide(int number, int divisor )
{
if(divisor == 0)
{
throw new ArgumentOutOfRangeException();
}
return number / divisor;
}
Quelle: https://www.develop.com/csharpcodecontracts

Code Contracts
{
Contract.Requires<ArgumentOutOfRangeException>( divisor != 0 );
}

Code Contracts
{
Contract.Requires<ArgumentOutOfRangeException>( divisor != 0 );
}
public int RandomDivisor()
{
Contract.Ensures( Contract.Result<int>() != 0 );
int d = new Random().Next( 100 );
return d;
}

Code Contracts
{
int d = new Random().Next( 100 );
return d;
}

Code Contracts
{
int d = new Random().Next(1, 100 );
return d;
}

Code Contracts
{
int d = new Random().Next(1, 100 );
return d;
}
public void Test()
{
int n = 10;
int d = RandomDivisor();
Contract.Assume( d != 0, "We assume d is never zero." );
return Divide( n, d );
}

Code Contracts
public class SpecialPoint
{
public int X { get; set; }
public int Y { get; set; }
[ContractInvariantMethod]
private void ClassContract()
{
Contract.Invariant( Y > X );
}
}

Code Contracts
public class MyRandomizer : IRandom
{
{
return 0;
}
}
[ContractClass( typeof( ContractForIRandom ) )]
public interface IRandom
{
int RandomDivisor();
}
[ContractClassFor( typeof( IRandom ) )]
public abstract class ContractForIRandom : IRandom
{
{
return default( int );
}
}

Clean mit visual studio

Weitere ähnliche Inhalte

Mehr von Hendrik Lösch

Clean mit visual studio

Hinweis der Redaktion