C# coding standards, good programming principles & refactoring

C# CODING STANDARDS, GOOD
PROGRAMMING PRINCIPLES
&
REFACTORING
Eyob Lube
10/11/2013

Topics
1. Coding Standards
2. The Total Cost of Owning a Mess
3. Principles of Good Programming
4. General Naming Conventions
5. Capitalization Conventions
6. Capitalization Rules for Identifiers
7. Methods (Functions)
8. Bad Smells in Code
9. Refactoring
10. Tools for better coding
11. References
2

1. Coding Standards
Why do we need coding Standards ?
• First, you may not agree with everything I say… that’s ok!
• Creates a consistent look to the code, so that readers can focus on content, not layout.
• Enables readers to understand the code more quickly by making assumptions based on
previous experience.
• Facilitates copying, changing, and maintaining the code.
• Produces more stable, reliable code
• Pick a standard for your project or company and stick to it!
• Make the standard easily available to each programmer (print or online)
• Enforce via code reviews, and pair programming.
• If the standard is insufficient or is causing problems update it as needed, but it should not be
“hacked”
3

2. The Total Cost of Owning a Mess
If you have been a programmer for more than two or three years, you have
probably been significantly slowed down by someone else’s messy code. If
you have been a programmer for longer than two or three years, you have
probably been slowed down by messy code.
The degree of the slowdown can be significant. Over the span of a year or
two, teams that were moving very fast at the beginning of a project can find
themselves moving at a snail’s pace. Every change they make to the code
breaks two or three other parts of the code. No change is trivial. Every
addition or modification to the system requires that the tangles, twists, and
knots be “understood” so that more tangles, twists, and knots can be
added. Over time the mess becomes so big and so deep and so tall, they
can not clean it up. There is no way at all.
4

2. The Total Cost of Owning a Mess…
As the mess builds, the productivity of the team continues to
decrease, asymptotically approaching zero. As productivity decreases, management
does the only thing they can; they add more staff to the project in hopes of
increasing productivity. But that new staff is not versed in the design of the system.
They don’t know the difference between a change that matches the design intent
and a change that thwarts the design intent. Furthermore, they, and everyone else
on the team, are under horrific pressure to increase productivity. So they all make
more and more messes, driving the productivity ever further toward zero.(See Figure
below)
5
Productivity vs. time
Clean Code: A Handbook of Agile Software Craftsmanship
by Robert C. Martin

6
3. Principles of Good Programming
I. KISS Design Principle
"Keep it simple, Stupid!".
"keep it short and simple" or "keep it simple
and straightforward".
The KISS principle states that simplicity
should be a key goal in design, and that
unnecessary complexity should be avoided.
II. SOLID Principles of Object Oriented Design
a. The Single Responsibility Principle (SRP)
b. The Open / Closed Principle (OCP)
c. The Liskov Substitution Principle (LSP)
d. The Interface Segregation Principle (ISP)
e. The Dependency Inversion Principle (DIP)

7
a. The Single Responsibility Principle (SRP)
There should never be more than one reason for a class to change. Basically, this
means that your classes should exist for one purpose only.

8
b. The Open Closed Principle (OCP)
The Open/Closed Principle states software entities (classes, modules, functions, etc.)
should be open for extension, but closed for modification.
Wikipedia
At first, this seems to be contradictory: how can you make an object behave differently
without modifying it?
The answer: by using abstractions, or by placing behavior(responsibility) in derivative
classes. In other words, by creating base classes with override-able functions, we are
able to create new classes that do the same thing differently without changing the base
functionality.
c. The Liskov Substitution Principle (LSP)
The Liskov Substitution Principle states that Subtypes must be substitutable for their
base types.
Agile Principles, patterns and Practices in C#
Named for Barbara Liskov, who first described the principle in 1988.

9
d. The Interface Segregation Principle (ISP)
The interface Segregation Principle states that Clients should not be forced to depend on
methods they do not use.
Prefer small, cohesive interfaces to “fat” interfaces.

10
e. The Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both should depend
on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Word Choice
Choose easily readable identifier names. For
example, a property named HorizontalAlignment is
more readable in English than AlignmentHorizontal.
Favor readability over brevity. The property name
CanScrollHorizontally is better than ScrollableX.
Do not use underscores, hyphens, or any other
nonalphanumeric characters.
4. General Naming Conventions
11

Abbreviations and Acronyms
• In general, you should not use abbreviations or
acronyms. These make your names less readable.
• Do not use abbreviations or contractions as parts
of identifier names.
• For example, use OnButtonClick rather than
OnBtnClick.
• Do not use any acronyms that are not widely
accepted, and then only when necessary.
General Naming Conventions
continued…
12

Meaningful Names
Names are everywhere in software. We name our
variables, functions, arguments, classes, packages, source files, directories…we
name and name and name. Because we do so much of it, we’d better do it well.
13

Meaningful Names…Continued
Use Intention-Revealing Names
• Choosing good names takes time but saves more than it takes. So
take care with your names and change them when you find
better ones. Everyone who reads your code (including you) will
be happier if you do.
• The name of a variable, function, or class, should answer all the
big questions. It should tell you why it exists, what it does, and
how it is used. If a name requires a comment, then the name
does not reveal its intent.
• int d; // elapsed time in days – the name d reveals nothing. It
does not evoke a sense of elapsed time, nor of days. We
should choose a name that specifies what is being measured
and the unit of that measurement.
• int elapsedTimeInDays
14

Use Intention-Revealing Names…
The varaible d could be renamed to one of the following:
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;
Choosing names that reveal intent can make it much easier to understand and change
code. What is the purpose of this code?
public List<int[]> getThem()
{
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4) list1.add(x);
return list1;
}
15

Why is it hard to tell what this code is doing? There are no complex expressions. Spacing
and indentation are reasonable. There are only three variables and two constants
mentioned. There aren’t even any fancy classes or polymorphic methods, just a list of
arrays (or so it seems).
The problem isn’t the simplicity of the code but the implicity of the code (to coin a
phrase): the degree to which the context is not explicit in the code itself. The code
implicitly requires that we know the answers to questions such as:
1. What kinds of things are in theList?
2. What is the significance of the zeroth subscript of an item in theList?
3. What is the significance of the value 4?
4. How would I use the list being returned?
16

The answers to these questions are not present in the code sample,but they could have
been. Say that we’re working in a mine sweeper game. We find that the board is a list of
cells called theList. Let’s rename that to gameBoard.
Each cell on the board is represented by a simple array. We further find that the zeroth
subscript is the location of a status value and that a status value of 4 means “flagged.” Just
by giving these concepts names we can improve the code considerably:
public List<int[]> getFlaggedCells()
{
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}
17

Notice that the simplicity of the code has not changed. It still has exactly the same number
of operators and constants, with exactly the same number of nesting levels. But the code
has become much more explicit.
We can go further and write a simple class for cells instead of using an array of ints. It can
include an intention-revealing function (call it isFlagged) to hide the magic numbers. It
results in a new version of the function:
public List<Cell> getFlaggedCells()
{
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
With these simple name changes, it’s not difficult to understand what’s going on. This is
the power of choosing good names.
18

Avoid Disinformation
• Example: Do not refer to a grouping of accounts as an accountList
unless it’s actually a List. The word list means something specific to
programmers. If the container holding the accounts is not actually a
List, it may lead to false conclusions. So accountGroup or
bunchOfAccounts or just plain accounts would be better. (It’s also not
good to include the type into the name)
•A truly awful example of disinformative names would be the use of
lower-case L or uppercase O as variable names, especially in combination.
The problem, of course, is that they look almost entirely like the constants
one and zero, respectively.
int a = l;
if ( O == l )
a = O1;
else
l = 01;
19

Make Meaningful Distinctions
• It is not sufficient to add number series or noise words, even though the compiler is
satisfied. If names must be different, then they should also mean something different.
• Number-series naming (a1, a2, .. aN) is the opposite of intentional naming. Such
names are not disinformative—they are noninformative; they provide no clue to the
author’s intention.
• Consider:
• Public static void CopyChars(char a1[], char a2[])
• Public static void CopyChars(char source [], char destination [])
• Noise word are another meaningless distinctions. Imagine that you have a Product
class if you have another called ProductInfo or ProductData, you have made the names
different without making them mean anything different. Info and Data are indistinct
noise words like a, an, and the.
• Noise words are redundant. The word variable should never appear in a variable name.
The word table should never appear in a table name. How is NameString better than
Name?
Use Pronounceable Names
private Date genymdhms;
//generation date, year, month, day, hour, minute second
vs
private Date generationTimestamp
20

Compare
class DtaRcrd102
{ private Date genymdhms;
private Date modymdhms;
private final String pszqint = "102";
/* ... */ };
to
class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;;
private final String recordId = "102";
/* ... */
};
Intelligent conversation is now possible:
“Hey, Mikey, take a look at this record! The generation timestamp is
set to tomorrow’s date! How can that be?”
21

Class Names
• Classes should have noun or noun phrase names like
Customer, WikePage, Account and AddressParser. Avoid words
like Processor, Data, or Info in the name of a class. A class name
should not be a verb.
Method Names
• Methods should have a verb or verb phrase names like
PostPayment, DeletePage, or SaveAccessors.
22

5. Capitalization Conventions
Casing Styles
The following terms describe different ways to case identifiers.
Pascal Casing
The first letter in the identifier and the first letter of each
subsequent concatenated word are capitalized. You can use Pascal
case for identifiers of three or more characters.
For example: BackColor
Camel Casing
The first letter of an identifier is lowercase and the first letter of
each subsequent concatenated word is capitalized.
For example: backColor
Uppercase
All letters in the identifier are capitalized.
For example: IO
23

6. Capitalization Rules for Identifiers
Identifier Case Example
Class Pascal AppDomain
Enumeration type Pascal ErrorLevel
Enumeration values Pascal FatalError
Event Pascal ValueChanged
Exception class Pascal WebException
Read-only static field Pascal RedValue
Interface Pascal IDisposable
Method Pascal ToString
Namespace Pascal System.Drawing
Parameter Camel typeName
Property Pascal BackColor 24

7. Methods (Functions)
• Should be very small (20 – 30 lines max ,not more
than 1 screen)
• Do one thing
• Use Descriptive Names
• Ideal number of arguments for a function is zero. Next
comes one, followed closely by two. Three arguments
should be avoided where possible.
• Prefer to pass by using a class variable instead of listing
5 or 10 function arguments.
• Arguments are hard they take a lot of conceptual
power.
• Delete commented out dead code, if anyone really
needs it, he should go back and check out a previous
version.
25

8. Bad Smells in Code
1. Duplicated Code
2. Long Method
3. Large Class
4. Long Parameter List
26

9. Refactoring
Refactoring is the process of improving your code after it has been written
by changing the internal structure of the code without changing the
external behavior of the code.
Reasons for Refactoring Code
1. Consolidating and eliminating “Like” or “Similar” Code
2. Breaking out an extraordinary long function into more manageable bites
3. Make error trapping easier to handle
4. Make code more readable and maintainable
5. Removing nested IF or logic Loops
6. Make it easier to document
7. Create Reusable code
8. Better class and function cohesion.
The benefits now are the following:
1. Similar code is now the same which is the way it was meant to be.
2. Since the code had the same purpose, it looks the same now and
behaves the same.
3. Code is in one spot instead of 5 – makes it easier for a base change
4. Error trapping is much more controlled.
27

10. Tools for better coding
1. Visual Studio
2. Resharper
3. Code Analysis
4. PowerCommands
5. FxCop
28

11. References
1. C# Coding Conventions (C# Programming Guide)
2. All-In-One Code Framework Coding Standards
3. Importance of Code Refactoring
4. Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
5. Refactoring: Improving the Design of Existing Code by Martin Fowler
6. .NET Coding Standards For The Real World (2012) by David McCarter on Jan 27, 2012
7. http://pluralsight.com/training
8. The S.O.L.I.D. Object Oriented Programming(OOP) Principles
9. Agile Priniciples, Patterns and Practices in C# By Robert C. Martin and Micah Martin
10. KISS principle
11. SingleResponsibilityPrinciple image
12. The Interface Segregation Principle (ISP) image
13. Dependency Inversion Principle (DIP) image
29

C# coding standards, good programming principles & refactoring

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to C# coding standards, good programming principles & refactoring (20)

Recently uploaded (20)

C# coding standards, good programming principles & refactoring

Editor's Notes