You are on page 1of 30

Coding Standard & Code Review

Milan Vukoje www.vukoje.net vukoje@gmail.com

Soprex
l SkfOffice2 l SkfOffice3 l Big5 l Quality

oriented l We are hiring…
l

Is code important? Code Refactoring Coding Standard Code Review Tools
 

mechanical process? guaranteed to be done 50-65% of overall effort 50-75% of overall errors

When software organization chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term.

--Ward Cunningham intentional debt (make up issues) unintentional debt Educate your managers

Coding Horror
Fear Stress Cargo cult programming/Just in case coding Strange bugs

 

Heisenbug - bug that disappears or alters its characteristics when an attempt is made to study it. Mandelbug - bug whose causes are so complex that its behavior appears chaotic. Schroedinbug - bug that manifests only after someone reading source code or using the program in an unusual way notices that it never should have worked in the first place. …

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactoring: Improving the Design of Existing Code --Martin Fowler

 

In a complex program, architectural guidelines give the program structural balance and construction guidelines provide low-level harmony, articulating each class as faithful part of a comprehensive design… Without a unifying discipline, your creation will be jumble of sloppy variations in style. Such variations are essentially arbitrary. One key to successful programming is avoiding arbitrary variations so that your brain can be free to focus on the variations that are really needed. -- Steve McConell

Framework Design Guidelines: Conventions,
Idioms, and Patterns for Reusable .NET Libraries

-- Krzysztof Cwalina and Brad Adams

Code Commenting Naming Code Layout Type Design Guidelines Member Design Exception Management Stored Procedures .NET types usage

CS – Code Commenting

l l

l

DO comment API. DO NOT comment whole methods or method bodies. If some code is not used, it should be deleted. DO comment complex methods, especially if/else statements.

l

CS - Naming
l l

l

l

If you are not able to come up with a right noun phrase you should rethink of a general design of the type. Most easily recognized names should be used for most commonly used types. Method names should describe what the method does and not how it is implemented. Names of derived types should contain, if appropriate, name of its base type.
public interface ISessionChannel<TSession> where TSession: ISession { TSession Session {get;} }

    

l

System.Delegate – Add suffix “EventHandler” to names of delegates that are used in events. Add suffix “Callback” to names of delegates other than those used as event handlers. Do not add suffix “Delegate” to a delegate.

l

CS - Type Design Guidelines
l Choosing
l DO

between class and structs

favour defining classes over interfaces. l AVOID using marker interfaces (interfaces with no members). l DO NOT use public nested types as a logical grouping construct; use namespaces for this. l DO favour using an enum over static constants.
l

CS - Property Design
DO NOT provide set-only properties. DO provide sensible default values for all properties. DO allow properties to be set in any order even if this results in a temporary invalid state of the object. Remember there is a strong expectation that setting a property is not much more expensive than setting a field. AVOID throwing exceptions from property getters. Property getters should be simple operations and should not have any preconditions. If a getter can throw an exception, it should probably be redesigned to be a method.

CS – Exception Handling
l l l

l l l

DO NOT catch exceptions that you can not handle. DO NOT cache exceptions just to rethrow them (without handling) CONSIDER wrapping specific exceptions thrown from a lower layer in a more appropriate exception, if the lower layer exception does not make sense in the context of the higher layer operation. AVOID catching and wrapping nonspecific exceptions. This is often undesired and is just another form of swallowing errors. DO specify the inner exception when wrapping exceptions.

CS - .NET types usage
l l

l

l

l

l

DO NOT use weakly typed collections in public APIs. DO use ReadOnlyCollection<T> or a subclass or ReadOnly-Collection<T> for properties or return values representing read-only collections. DO NOT return null values from collection properties or from methods returning collections. If there is no items for collections return empty collection. This rule implies to DataTable type also. DO NOT return snapshots collections from properties. Properties should return live collections. For string manipulation StringBuilder class should be used because it is far more efficient than calling methods on String class (e.g. string concatenation). DO use System.Uri to represent URI and URL data instead of string.

Unified code Faster code understanding/modifying Easier “code smell” identification Cleaner API Avoiding “genius” solutions (KISS) Reducing chances for bugs real working framework

Adopting the standard
l Real

challenge l Needs support in upper management and team leader determination l Should everybody comply? l Redefine what does “done” mean
l

Getting clean… code
l Start

small l Add rules incrementally l Divide and conquer l Use tools l Intensive code reviews l Fight the Klingons!
l

Code Reveiw

What to review?
l Newbie's

code l Challenging tasks l Spikes l Buggy code l Architecture significant tasks l Widely reused code

Code Review Checklist
l Clarity l Maintainability l Accuracy l Security l Scalability l Reusability l Efficiency l OOP

principles, encapsulation

CR challenges
l Keep

it integrated l Don’t overdo it – Perfect is the enemy of good, and good is what we want. l Encourage positive critics l Effective CR meetings

CR meetings
l Focus

on enhancing code rather than criticism l Integrate with refactoring l Create refactoring issue or add TODO comments l Avoid arguments about coding in general and theoretical discussion l Discover bugs and issues early
l

VS refactoring features VS compiler warnings Code Analysis StyleCop TFS check in policy Great way to learn .NET Performance issues Suppressions
 

Pitanja?

Milan Vukoje www.vukoje.net vukoje@gmail.com