How much should you rely on your IDE to govern your coding style? How many asserts should a test case have or not have? How much work should a constructor (not) do? How do you name your classes and other identifiers? How closed or open should your classes be? How do you lay out your code? These questions and others have standard answers based on received and repeated mantras, practices that are communicated in good faith to be passed on as habits. But how much reason supports these assertions? It turns out that the advice often fails, even for the novices they are intended to guide, or simply doesn't make sense.
This talk has little respect for ritual and tradition and takes no prisoners: What actually makes sense and what doesn't when it comes to matters of practice? What guidelines offer the greatest effect and the greatest learning?
About our speaker:
Kevlin is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He has been a columnist for various magazines and web sites and is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know. He lives in Bristol and online.