Clean Code: Intro, Clean Code and Meaningful Names (up to the end of chapter 2)

[Tim Penhey]

On 20/09/13 04:57, Mark Canonical Ramm-Christensen wrote:
> *Rules of Thumb for Code Cleanup*
> 
> But, for everyday work, I'm also very aware that we need some shortcuts,
> and rules of thumb. We can't make every single code cleanup decision by
> trying to weigh all the costs and all the benefits.
> 
> Given that Juju is a product that already has real users, and has grown
> to a significant size I would like to propose a set of rules of thumb
> that make sense to me: 
> 
>   *  knowingly acquiring significant (as in will cost a lot later)
>     technical debt a bad idea and new debt should be an exception rather
>     than the rule. 
>   *  we need to pay down debts/when we see that they are starting to
>     cost something/ in terms of further development work. 
> 
> The second rule might need a bit of unpacking it means: 
> 
>   * doing drive-by cleanup as we write new features, 
>   * refactoring and de-duplicating existing code to remove impediments
>     to progress as needed to build new features
> 
> But it does not mean: 
> 
>   * going through a massive cleanup effort to  we fix every naming
>     inconsistency
>   * finding and purging every possible bit of code duplication everywhere
>   * finding the perfect solution to every question of where to draw the
>     lines of abstraction, and then going back and fixing all the code to
>     match that ideal abstraction layer

While this is somewhat off topic, I agree with these rules of thumb.

> Reading "Clean Code" could be about a lot of things. It could be about
> forging a team with a shared understanding of code quality. That would
> be amazing and valuable. Or it could be about double guessing every old
> decision, and trying to fix everything that ever "went wrong" up to this
> point in the project -- which would be painful and a complete waste.  
> 
> My hope is that this book helps us all grow a shared vocabulary of code
> quality, and to improve the speed and fluency with which we can handle
> code quality questions.   

I agree entirely here.  I found a lot of benefit from reading this book,
even though a lot of it seemed like common sense and things I have done
for ages.  It is nice to be able to point at a book and say "see, it
isn't just me that thinks like this".

Don't get me wrong, there are some things that I don't agree with in the
book, but I think that everyone will have that, and most likely, have it
in different places.

But I do feel that the aim is to have a common understanding and
vocabulary around what clean code means.

The intent was always forward looking, not to navel gaze and look back
at past decisions.

> So, to sum up my view on all of this: growing the capacity of the team
> is my number one goal, because it makes /everything/ easier in the future.  

Agreed.

Tim