Code Correctness, Readability, Maintainability Telerik Software Academy Telerik School Academy

 Why Quality Is Important?  Software Quality: External and Internal  What is High-Quality Code?  Code Conventions  Managing Complexity  Characteristics of Quality Code  Unit Testing  Recommended Books 2

What does this code do? Is it correct? 4 static void Main() { int value=010, i=5, w; int value=010, i=5, w; switch(value){case 10:w=5;Console.WriteLine(w);break;case 9:i=0;break; switch(value){case 10:w=5;Console.WriteLine(w);break;case 9:i=0;break; case 8:Console.WriteLine("8 ");break; case 8:Console.WriteLine("8 ");break; default:Console.WriteLine("def ");{ default:Console.WriteLine("def ");{ Console.WriteLine("hoho ");} Console.WriteLine("hoho ");} for (int k = 0; k < i; k++, Console.WriteLine(k - 'f'));break;} { Console.WriteLine("loop!"); } for (int k = 0; k < i; k++, Console.WriteLine(k - 'f'));break;} { Console.WriteLine("loop!"); }}

Now the code is formatted, but is still unclear. 5 static void Main() { int value = 010, i = 5, w; int value = 010, i = 5, w; switch (value) switch (value) { case 10: w = 5; Console.WriteLine(w); break; case 10: w = 5; Console.WriteLine(w); break; case 9: i = 0; break; case 9: i = 0; break; case 8: Console.WriteLine("8 "); break; case 8: Console.WriteLine("8 "); break; default: default: Console.WriteLine("def "); Console.WriteLine("def "); Console.WriteLine("hoho "); Console.WriteLine("hoho "); for (int k = 0; k < i; k++, for (int k = 0; k < i; k++, Console.WriteLine(k - 'f')) ; Console.WriteLine(k - 'f')) ; break; break; } Console.WriteLine("loop!"); Console.WriteLine("loop!");}

 External quality  Does the software behave correctly?  Are the produced results correct?  Does the software run fast?  Is the software UI easy-to-use?  Is the code secure enough?  Internal quality  Is the code easy to read and understand?  Is the code well structured?  Is the code easy to modify? 6

 High-quality programming code:  Easy to read and understand  Easy to modify and maintain  Correct behavior in all cases  Well tested  Well architectured and designed  Well documented [click for fun] click for funclick for fun  Self-documenting code  Well formatted 7

 High-quality programming code:  Strong cohesion at all levels: modules, classes, methods, etc.  Single unit is responsible for single task  Loose coupling between modules, classes, methods, etc.  Units are independent one of another  Good formatting  Good names for classes, methods, variables, etc.  Self-documenting code style 8

 Code conventions are formal guidelines about the style of the source code:  Code formatting conventions  Indentation, whitespace, etc.  Naming conventions  PascalCase or camelCase, prefixes, suffixes, etc.  Best practices  Classes, interfaces, enumerations, structures, inheritance, exceptions, properties, events, constructors, fields, operators, etc. 10

 Microsoft has official C# code conventions  Design Guidelines for Developing Class Libraries:  Semi-official JavaScript code conventions  styleguide.googlecode.com/svn/trunk/javascriptguide.xml styleguide.googlecode.com/svn/trunk/javascriptguide.xml styleguide.googlecode.com/svn/trunk/javascriptguide.xml  Large organization follow strict conventions  Code conventions can vary in different teams  High-quality code goes beyond code conventions  Software quality is a way of thinking! 11

 Managing complexity has central role in software construction  Minimize the amount of complexity that anyone’s brain has to deal with at certain time  Architecture and design challenges  Design modules and classes to reduce complexity  Code construction challenges  Apply good software construction practices: classes, methods, variables, naming, statements, error handling, formatting, comments, etc. 13

 Key to being an effective programmer:  Maximizing the portion of a program that you can safely ignore  While working on any one section of code  Most practices discussed later propose ways to achieve this important goal 14

 Correct behavior  Conforming to the requirements  Stable, no hangs, no crashes  Bug free – works as expected  Correct response to incorrect usage  Readable – easy to read  Understandable – self-documenting  Maintainable – easy to modify when required 16

 Good identifiers' names  Good names for variables, constants, methods, parameters, classes, structures, fields, properties, interfaces, structures, enumerations, namespaces,  High-quality classes, interfaces and class hierarchies  Good abstraction and encapsulation  Simplicity, reusability, minimal complexity  Strong cohesion, loose coupling 17

 High-quality methods  Reduced complexity, improved readability  Good method names and parameter names  Strong cohesion, loose coupling  Variables, data, expressions and constants  Minimal variable scope, span, live time  Simple expressions  Correctly used constants  Correctly organized data 18

 Correctly used control structures  Simple statements  Simple conditional statements and simple conditions  Well organized loops without deep nesting  Good code formatting  Reflecting the logical structure of the program  Good formatting of classes, methods, blocks, whitespace, long lines, alignment, etc. 19

 High-quality documentation and comments  Effective comments  Self-documenting code  Defensive programming and exceptions  Ubiquitous use of defensive programming  Well organized exception handling  Code tuning and optimization  Quality code instead of good performance  Code performance when required 20

 Following the corporate code conventions  Formatting and style, naming, etc.  Domain-specific best practices  Well tested and reviewed  Testable code  Well designed unit tests  Tests for all scenarios  High code coverage  Passed code reviews and inspections 21

 You have already done unit testing  Manually, by hand  Manual tests are less efficient  Not structured  Not repeatable  Not on all your code  Not easy to do as it should be 23

 Tests are specific pieces of code  In most cases unit tests are written by developers, not by QA engineers  Unit tests are released into the code repository (TFS / SVN / Git) along with the code they test  Unit testing framework is needed  Visual Studio Team Test (VSTT)  NUnit, MbUnit, Gallio, etc. 24

 All classes should be tested  All methods should be tested  Trivial code may be omitted  E.g. property getters and setters  Private methods can be omitted  Some gurus recommend to never test private methods  this can be debatable  Ideally all unit tests should pass before check- in into the source control repository 25

 Unit tests dramatically decrease the number of defects in the code  Unit tests improve design  Unit tests are good documentation  Unit tests reduce the cost of change  Unit tests allow refactoring  Unit tests decrease the defect-injection rate due to refactoring / changes  Prevent bugs from happening again 26

 Team Test (VSTT) is very well integrated with Visual Studio  Create test projects and unit tests  Execute unit tests  View execution results  View code coverage  Located in the assembly Microsoft.VisualStudio.QualityTools. UnitTestFramework.dll 27

 Test code is annotated using custom attributes:  [TestClass] – denotes a class holding unit tests  [TestMethod] – denotes a unit test method  [ExpectedException] – test causes an exception  [Timeout] – sets a timeout for test execution  [Ignore] – temporary ignored test case  [ClassInitialize], [ClassCleanup] – setup / cleanup logic for the testing class  [TestInitialize], [TestCleanup] – setup / cleanup logic for each test case 28

 Assertions check a condition  Throw exception if the condition is not satisfied  Comparing values for equality  Comparing objects (by reference)  Checking for null value 29 AreEqual(expected_value, actual_value [,message]) AreSame(expected_object, actual_object [,message]) IsNull(object [,message]) IsNotNull(object [,message])

30 public class Account { private decimal balance; private decimal balance; public void Deposit(decimal amount) public void Deposit(decimal amount) { this.balance += amount; this.balance += amount; } public void Withdraw(decimal amount) public void Withdraw(decimal amount) { this.balance -= amount; this.balance -= amount; } public void TransferFunds( public void TransferFunds( Account destination, decimal amount) Account destination, decimal amount) { … } { … } public decimal Balance public decimal Balance { … } { … }}

31 using Microsoft.VisualStudio.TestTools.UnitTesting; [TestClass] public class AccountTest { [TestMethod] [TestMethod] public void TransferFunds() public void TransferFunds() { Account source = new Account(); Account source = new Account(); source.Deposit(200.00M); source.Deposit(200.00M); Account dest = new Account(); Account dest = new Account(); dest.Deposit(150.00M); dest.Deposit(150.00M); source.TransferFunds(dest, M); source.TransferFunds(dest, M); Assert.AreEqual(250.00M, dest.Balance); Assert.AreEqual(250.00M, dest.Balance); Assert.AreEqual(100.00M, source.Balance); Assert.AreEqual(100.00M, source.Balance); }}

Live Demo

Code Complete, 2nd Edition, Steve McConnell, ISBN , Refactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, ISBN , Test Driven Development: By Example, Kent Beck, ISBN

Questions?

 C# Telerik Academy  csharpfundamentals.telerik.com csharpfundamentals.telerik.com  Telerik Software Academy  academy.telerik.com academy.telerik.com  Telerik Facebook  facebook.com/TelerikAcademy facebook.com/TelerikAcademy  Telerik Software Academy Forums  forums.academy.telerik.com forums.academy.telerik.com