the evolution of good code

Download The Evolution of Good Code

Post on 27-Aug-2014

1.597 views

Category:

Software

0 download

Embed Size (px)

DESCRIPTION

A talk describing how best practices for writing code have changed throughout the last 21 years. What do we think of as good code, and how has our perception of good code changed form the early days of programming to the exciting times we live in now? In this talk we do a bit of digging into the short history of programming, by looking at the available literature and various best practices promoted throughout the ages to improve your code.

TRANSCRIPT

  • Arjan van Leeuwen The Evolution of Good Code ACCU 2014 @avl7771
  • Take one of each ! !
  • "The past is a foreign country: they do things differently there." L.P. Hartley
  • GoodSolidReadable MaintainableElegant Bug-free reliableTestable Debuggable CLEAN
  • The bookshelf A man may as well expect to grow stronger by always eating as wiser by always reading.! Jeremy Collier
  • Writing Solid Code Steve Maguire! Microsoft Programming! 1993! Microsofts Techniques for Developing Bug-Free C Programs
  • The Pragmatic Programmer Andrew Hunt & David Thomas! Addison Wesley! 2000! examines the core process - taking a requirement and producing working, maintainable code that delights its users
  • Code Complete Steve McConnell! Microsoft Programming! 2004 (1st Edition 1993)! A Practical Handbook of Software Construction - Helps you build the highest quality code
  • Clean Code Robert C. Martin (Uncle Bob)! Prentice Hall! 2009! A handbook for Agile Software Craftsmanship How to write good code and how to transform bad code into good code
  • 97 Things Every Programmer Should Know Various Artists, edited by Kevlin Henney! OReilly! 2010! Collective Wisdom from the Experts youll expand your skills by learning appropriate best practices
  • Growing Object-Oriented Software, Guided by Tests Steve Freeman & Nat Pryce! Addison Wesley! 2010! Two TDD pioneers show how to let tests guide your development and grow software that is coherent, reliable, and maintainable
  • The Art of Readable Code Dustin Boswell & Trevor Foucher! OReilly! 2011! Simple and Practical Techniques for Writing Better Code
  • Guess the book! If we encounter a man of rare intellect, we should ask him what books he reads.! Ralph Waldo Emerson
  • 2011 2009 ! ! 1993 Use Hungarian notation for variables Although names like pch look funny and are hard to pronounce, they are lled with information.! Conveying information is far more important in naming your variables than being able to stand up and read your code aloud during a program review. /* pointer to character pointer */ char **ppch;
  • ! ! 1993 Use Hungarian notation for variables Although names like pch look funny and are hard to pronounce, they are lled with information.! Conveying information is far more important in naming your variables than being able to stand up and read your code aloud during a program review. /* pointer to character pointer */ char **ppch;
  • Dont use Hungarian notation for variables In modern languages we have much richer type systems, and the compilers remember and enforce the types.! Nowadays HN and other forms of type encoding are simply impediments. They make it harder to read the code. /* pointer to character pointer */ char **ppch; 2011 2009 ! ! 1993
  • Dont use Hungarian notation for variables In modern languages we have much richer type systems, and the compilers remember and enforce the types.! Nowadays HN and other forms of type encoding are simply impediments. They make it harder to read the code. /* pointer to character pointer */ char **ppch; 2009
  • 2004 Dont use Yoda Conditions Putting constants and expressions on the left-hand side of comparisons works only when one of the operands is a constant or an expression.! If instead you use a compiler switch, the compiler would alert you to every possible assignment bug. 2011 ! ! 1993 if (10 == x) // if 10, x is!
  • Dont use Yoda Conditions Putting constants and expressions on the left-hand side of comparisons works only when one of the operands is a constant or an expression.! If instead you use a compiler switch, the compiler would alert you to every possible assignment bug. if (10 == x) // if 10, x is! ! ! 1993
  • 2010 Enforce singletons If you want to dene a class that allows only one object to be instantiated, enforce this by hiding all the constructors of the class and providing a static routine to access the classs single instance. public class MaxId { private MaxId() {} public static MaxId GetInstance() { /*..*/ } } 2004 ! ! 1993
  • Enforce singletons If you want to dene a class that allows only one object to be instantiated, enforce this by hiding all the constructors of the class and providing a static routine to access the classs single instance. public class MaxId { private MaxId() {} public static MaxId GetInstance() { /*..*/ } } 2004
  • 2011 Prefer Write-Once Variables The more places a variable is manipulated, the harder it is to reason about its current value! Variables that are a permanent xture are easier to think about! Immutables tend to more often be trouble-free 2004 ! ! 2000
  • 2011 Prefer Write-Once Variables The more places a variable is manipulated, the harder it is to reason about its current value! Variables that are a permanent xture are easier to think about! Immutables tend to more often be trouble-free
  • 2011 Design for Unit Tests Most important, is it possible to automatically and thoroughly validate the design using a unit test? If not, you should consider using an alternative design that can be tested. 2004 ! ! 1993
  • Design for Unit Tests Most important, is it possible to automatically and thoroughly validate the design using a unit test? If not, you should consider using an alternative design that can be tested. ! ! 1993
  • Names and aesthetics Small changes that help you understand code
  • Use Hungarian Notation for Variables Prex indicates type or intended use! Widely used after use in Microsoft Windows C libraries! Systems Hungarian vs. Apps Hungarian char ch; /* a plain old character */ bool f; /* flags that are always TRUE or FALSE */ char *pch; /* a character pointer */ char **ppch; /* pointer to a character pointer */ char *szName; /* a zero-terminated string */
  • Why? Makes wrong code look wrong [Maguire93], [McConnell04]! Easy to decipher pointer expressions [McConnell04]! Semantic prexes add information that compiler doesnt know about [McConnell04]! Standardized prexes encourage consistent naming [McConnell04]
  • Why not? Encoding adds burden of deciphering [Martin09]! Not necessary for types anymore [Martin09]! Functions and classes are shorter now [Martin09]! Inappropriate in object-oriented systems [Hunt00]! Code is read more than its written [Hunt00]
  • Use Hungarian Notation for Variables 1993 2000 2004 2009 2011
  • Specify interface or implementation in class name Denote in the class name when a class is an interface or when it implements an interface! Typically using prex I for Interface and/or postx Impl for Implementation class IBloober { virtual void blob() = 0; }; ! class BlooberImpl : public IBloober { virtual void blob(); };
  • Why? See whether you are using an interface just from the name
  • Why not? Users shouldnt (have to) know theyre dealing with an interface, better to encode the Impl [Martin09]! Names ending in Impl duplicate information [Freeman10]! Can indicate poorly named interface or design [Freeman10]
  • Specify interface or implementation in class name 1993 2004 2009 2010 ? ?
  • Align similar statements Can be used wherever similar statements are done on multiple lines! Purely aesthetic enhancement customerPurchases = customerPurchases + CustomerSales(customerID); customerBill = customerBill + customerPurchases; totalCustomerBill = customerBill + PreviousBalance(customerID) + LateCharge(customerID); customerRating = Rating(customerID, totalCustomerBill);
  • Why? Alignment scheme shows statements belong together [McConnell93]! Neater listing and quicker scanning [McConnell93]! Column edges provide visual handrails [Boswell11]! Doesnt take much work [Boswell11]