Good Code

We often talk about good code — that we would like to write it, that there isn't enough of it, that it should not be considered an optional attribute of a codebase. We often talk about it but, when it comes to being precise, we don't always agree what constitutes good code, nor do we necessarily share a common view on its value.

This half-day workshop explores what properties we want from a codebase and, therefore, what we can deduce to be good. These conclusions can sometimes be surprising and counter-intuitive! This session will explore some common guidelines on what is considered good, from expression to subsystem, from naming to tests, from fluent to SOLID. We will look at the consequences of good and not-so-good code from point of view of economics, day-to-day work, people and runtime performance and reliability.

What you'll learn from this tutorial:
You will learn that what we consider to be good is not fixed and absolute, but nor is it arbitrary. What we establish as good is an empirical enquiry based on people, time and problem solving. We can feed this from and into code reviews, coding guidelines and our conversations about code and conventions.

Comments

Comments are closed.