Clean Coding techniques with Code Review best practices.

1. CLEAN CODING
AHMED HELMY | SENIOR SOFTWARE DEVELOPER

2. AGENDA
 What Are Code Reviews?
 What Is It?
 Why Do It?
 How to Do It??
 How to Not Do It?
 Lessons for C#
 Lessons for Classes
 Lessons for ASP.NET
 Lessons for Architecture
 References and Discussion

3. WHAT ARE CODE REVIEWS?
 What Is It?
 Read the code
 Learn by looking at your own codebase
 Search for patterns and anti-patterns
 Quantify the quality of your code
 Not exhaustive… spot check

4. WHAT ARE CODE REVIEWS?
 Why Do Code Review?
The job of a code review is to determine
what is being done well as well as what can
be done better. It is not a witch hunt.
Sharing the findings of a code review
makes all developers involved better.

5. WHAT ARE CODE REVIEWS?
 How to Review Code?
 Taking your experience to bear…
 Find things to laud and things to fix
 Look of common problems, not one-off issues
 Review 200-400 lines at a time
 Review the whole code-base is time consuming
 No code is perfect code
 Maintainable code is a feature!

6. WHAT ARE CODE REVIEWS?
 How to Not Review Code?
 There are patterns to reviewing code – there are anti-patterns too
 Don’t get emotional
 Don’t focus on blame
 Don’t redesign the code
 Don’t judge based on how you would have code it
 Don’t include one-off problems
 Trying to find patterns to fix, not single bugs

7. LESSONS FOR C#
 Magic Numbers and Strings
 Replace with strongly typed variables
 Large Method Bodies
 More than one-page span
 Avoid comments if there is another way to describe your code (self-descriptive)
 const vs. readonly
 If

8. LESSONS FOR C#
 String Concatenation
 string.Concat()
 string.Format()
 StringBuilder

9. LESSONS FOR C#
 Bad IDisposable Usage
 Use using scope statement

10. LESSONS FOR CLASSES
 Interfaces and Abstract Classes
 You can only have one base class, but you can implement multiple interfaces
 “Is A” relationship for abstract class
 “I Can” relationship for interfaces
 Abstract class can have default implementation
 Excess Derivation
 Class inheritance trees
 Static classes and Singletons
 Instead of implementing Singleton, you can use static classes instead as it’s a singleton, it will reduce code to implement singleton
and easier to use
 Nested class usage
 Using nested class reduce simplicity and maintainability
 Hiding class members with ‘new’
 Auto Properties vs. Private Members
 If no business needed to be done in setting and getting, use auto properties instead of backing fields

11. LESSONS FOR ASP.NET
 Using Encoding in Markup Files
 Making sure you are helping browsers by telling them what encoding you’re using
 Make sure you are not only using the meta tag
 But you also make sure file> advanced save options use same character set

12. LESSONS FOR ASP.NET
 Edge Versions of Browsers
 If you are using HTML5 websites, make sure the browsers know you want to use edge rendering
 If your app using older browser maybe the tag is ignored
 The tag ensure you are using latest version of browser you are using

13. LESSONS FOR ASP.NET
 Embedding JS/CSS on a Page
 Eliminating embedded JavaScript and Style Sheets helps the browser improve
caching of your code
 Lose page caching as it’s imported every time it’s called
 Instead move it to files

14. LESSONS FOR ASP.NET
 Content Delivery Networks
 Use Content Delivery Networks so that browser caching can improve startup time for new users
 Bundles.
 Concatenating CSS
 Reduce round-trips with fewer CSS files means you’re less likely to run into browser limits of CSS

15. LESSONS FOR ASP.NET
 Razor Lessons
 The less code inside Razor file the better
 Remove C# code from view
 Also notice using statement in view

16. LESSONS FOR ASP.NET
 Caching
 Creating cached objects inside per-request classes isn’t necessary and adds complexity
 Overuse of Web API attributed Routing
 Routing tables are still a valid way of doing routing for much of your code
 Use Route Prefix
 Use Routing config

17. LESSONS FOR ARCHITECTURE
 Not Invented Here Syndrome
 Deciding that you are smarter than the community of the framework will lead to trouble
 Collective intelligence will always be smarter than one developer or even a small team
 Don’t build it unless you’re doing something very special
 That’s why communities exist
 Examples
 Custom data caching layers, instead of relying on caching systems
 In-house ORM/Data Access
 MVC Filters with Business Logic, It’s hard to be tested, instead put it in your business layer
 Don’t to build a great piece of code to prove you are worth (you want be the lead architect or head of
development)
 Buy, borrow, key parts of your system and focus on the hard problems, domain specific problems

18. LESSONS FOR ARCHITECTURE
 Too Many Layers
 Creating layers of abstraction for their own sake is seldom a good idea
 As Developers, we like architecture diagrams, we like to see the big picture of how system works
 We can get caught in the idea that more layers and abstraction layers are better… THEY ARE NOT, it will add
complexity too
 If system will change from using SQL server to use MongoDB or any other engine, change is not that easy as you change your
abstraction layer for data access, it’s a huge architectural change and the smallest part you will be concerned with is your data
access layer (schema, stored procedures, storage, relations, business logic, etc…)
 A lot of DTOs (validation, same classes)
 Hops
 You need to maintain these layers

19. LESSONS FOR ARCHITECTURE
 Integration Problems
 Skipping continuous integration or unit testing is going to affect code quality
 Lack of unit tests
 You can’t determine code quality without tests
 Manual testing is good, but doesn’t scale
 If you are not running tests, your users are your testers
 Writing tests for client-side and server-side code
 When they are different (e.g. web)
 Most code smell originated in lack of testing
 Unit tests are more valuable for regression than creation
 Continuous integration
 Building code frequently improves code quality
 Integration problems are surfaced earlier
 Running automated unit tests helps find regression bugs
 Breaking the build should be enforced by shame, not reprimands
 On large teams, this becomes even more important
 You should know the state of your code at all times

20. LESSONS FOR ARCHITECTURE
 Dependency Injection
 Using Dependency Injection is great, but defeating with hard problems isn’t any better than none
 Circular Dependencies
 Logger with Repository
 Lazy Loading Problems in EF
 Understanding that your Entity Framework code is executing on the server is important
 Joins
 Large Resultsets in EF
 Paging
 Big DMX Problems in EF
 Sub diagrams

21. REFERENCES & DISCUSSION
 Lessons from Real World .NET Code Reviews by Shawn Wildermuth