Of course, any Java programmer knows how to write a method. But is that really the case? Many programmers find they code more by habit — habits picked up from frameworks, IDE defaults and a random selection of blogs — than by reason. This talk tries to dissect some common habits with reason to reveal, well, how to write a method.
We all know how to write a method. We all know how to write a class. We all understand how to name a field. We all understand the practices we use, their deep rationale and their implications. We are perfectly rational, reasoned and unbiased about how we code and the practices we employ. Then again... perhaps not.
It turns out that we pick up habits and practices without being aware of them, retrospectively creating justification and rationale for what we do, whether it is naming conventions, indentation, control flow, use of language features, commenting, class layout, etc. All too often many things that have been considered good practice are discouraged because of IDE defaults or memes and habits emerging from vocal developers.
This session tries to take a more rational approach that allows you to evaluate and improve how you write methods. There is a good chance you won't agree with everything as many common Java habits are questioned and subjected to merciless reasoning.
Kevlin is an independent consultant, trainer and writer based in the UK. 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 the 97 Things Every Programmer Should Know site and book.