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

[Gustavo Niemeyer]

I'll take Michael's reply as an arbitrary entry point [1] to balance
the conversation a bit, which is ironic because I'm usually sitting
far to the other side of this picture, fighting for coherence and
perfection.

But then, while the fight for code improvement is a good fight, it's
also worth remembering that every day there are systems being made
extremely popular with whales hidden inside them, and people don't
even notice that the code underneath is using "context" or "ctx" as
the variable name. In fact, not even contributors care much about
that, as long as you have a solid user base and user experience.

This isn't, by all means, to suggest that we should stop caring about
the quality of our code base. I'm all for improving variable names,
type names, and whatever else, as people who actually worked with me
can confirm. It's rather just a small reminder that perfect code comes
second to having a relevant product.

In terms of books, there are indeed lots of good ideas in Clean Code.
For the flip-side of the coin, I recommend Dreaming in Code.


[1] Okay, it wasn't entirely arbitrary. I've actually always had a
great time debating issues with Michael. :-)


On Tue, Sep 17, 2013 at 4:11 AM, Michael Nelson
<michael.nelson at canonical.com> wrote:
> On Tue, Sep 17, 2013 at 7:42 AM, Andrew Wilkins
> <andrew.wilkins at canonical.com> wrote:
>> Decent read so far. Lots of reasonable ideas (obvious ideas, even!), though
>> some were a bit too dogmatic for me to swallow whole.
>>
>> I think for me the most important sections were (in chapter 2):
>>  - Use Intention Revealing Names,
>>  - Add Meaningful Context, and
>>  - (to a lesser degree) Don't Add Gratuitous Context
>>
>> "Use Solution Domain Names" before "Use Problem Domain Names" also resonates
>> with me. Juju hasn't been too bad about this, but I've worked on things
>> before where it's taken a lot of effort to understand things simply because
>> the names were in the problem domain when they didn't need to be. This makes
>> it difficult to ramp up. I think this is especially important to juju, since
>> it's Open Source. If we want to encourage contributions, then it's important
>> to minimise the barriers to entry.
>
> (just joining the book review for the ride - I hope it's not open to
> juju-devs only)
>
> This was one of the 'aha' moments for me in chapter 2 - the worth of
> solution domain names for better communication with other readers of
> the code (who generally will be more familiar with the domain of
> computer science than the domain of the problem). Additionally I think
> that using solution domain names consistently, where appropriate,
> gives us a lot more opportunity for improving our own heuristics of
> various pros and cons for patterns in different contexts. (But the
> author adds one or two reasons for problem domain names too).
>
> I also enjoyed the format of the 1st chapter... there are great
> opportunities to learn from each other generally in
> software-engineering (we're doing it constantly), but more often that
> not it's at the code-review level. It was nice to read some personal
> reflections from people who've gathered a huge base of experience -
> and feel a little mentored by the masters :-)
>
> -Michael
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
gustavo @ http://niemeyer.net