Confident Code

Hi HN. If you get some value out of these slides, great! But please, do me a favor: don't try too hard to construct a narrative from a stack of slides which:<p>a) represent about 15% of the actual semantic content of the presentation; and<p>b) are shaped by the consideration that there's a limit to how much code you can put on a slide and have it still be readable.<p>A lot of this material has been covered in more detail on my blog (<a href="http://avdi.org/devblog" rel="nofollow">http://avdi.org/devblog</a>) For instance, I wrote a whole article about Maybe, NullObject, and the limits of the ability to make objects falsy here: <a href="http://avdi.org/devblog/2011/05/30/null-objects-and-falsiness/" rel="nofollow">http://avdi.org/devblog/2011/05/30/null-objects-and-falsines...</a>

Here's a video of a recent (July 2011) version of the talk.<p><a href="http://confreaks.net/videos/614-cascadiaruby2011-confident-code" rel="nofollow">http://confreaks.net/videos/614-cascadiaruby2011-confident-c...</a>

This is great, but I'm a little worried about the custom Maybe function that slipped in about halfway through. Unless it's part of a standard framework (like ActiveSupport), if you use it in your projects you're likely going to find that:<p>a) Integrating with other codebases that don't use Maybe will result in code with an inconsistent style, and<p>b) If Maybe (or something like it) catches on enough, you'll hit collisions where two projects or libraries have different ideas of what Maybe means. (Maybe one uses <i>NilClass</i>, the other the custom <i>NullClass</i>, for example.)<p>(The PHP community has taken this to the extreme, with developers getting burnt over and over again with differing "standard" components using the same set of names.)

It seems to me that the essence of this idea is that you attack a problem in stages, and that each stage should have completely prepared you for the next.<p>That's where the confidence comes in; you can move forward knowing that your assumptions will hereafter <i>always</i> apply.<p>Upvote for NullObject pattern -- by far my favorite pattern. Unlike most 'Design Patterns', this is a useful and non-obvious idea no matter what language you work with.

I disagree about the point this presentation starts from. It's a bad code that's refactored in a way that I'm not sure is more clear, but definitely makes it longer... Why not split the work to make the process clearer instead of trying to flatten what's already there? Some concerns I'd have:<p>Making sure message is an array even if it's X instead. Why do that at all? Why is there an "else" in the first place? It's not like you can support every possible type, so why not say - either it's an array, or you pass a wrong type?<p>Why is the code for obtaining message in that function? Why is a similar code for destination there? Why is EPIPE being treated the same as normal response from the process?<p>How about starting with this instead:<p><pre><code> messages = normalise_messages(message) command = construct_command(options) output = get_results(messages, command) @logger.info("Wrote to #{destination_description(options[:out])}") output </code></pre> The rest is implementation details...

I've seen a number of really beautiful presentations like this recently. The page source indicates that it was generated from Org-mode. How much tweaking does it get to create a presentation like this, and is there any way I could see the source?

I like the attitude, but can't help thinking that using a decent modern statically typed language prevents half of the problems that this article poses to solve to begin with.

I tried to code like this already, but one scenario I've found that is ruining this style is external API calls.<p>I'm now finding my code heading back to the old littered style whenever I have to update or get information from someone else's API just because I have to handle potential failure there and then.<p>Very frustrating, anyone got any insights on how they're dealing with it?

Confident coding comes from understanding the language.<p><pre><code> Array({:foo=&#62;1}).map{|h| h[:foo]} TypeError: Symbol as array index [{:foo=&#62;1}].flatten.compact.map{|h| h[:foo]} =&#62; [1]</code></pre>

Recently I have been thinking a lot about Dependency Injection. It has clear benefits - like in testing - but there is also something that resonated with my preferences on a different level. It has been puzzling me for some time until I identified it - DI let's you code with less digressions: <a href="http://perlalchemy.blogspot.com/2011/10/concentration-and-flow-or-yet-another.html" rel="nofollow">http://perlalchemy.blogspot.com/2011/10/concentration-and-fl...</a>

<i>Array("foo\nbar") # =&#62; ["foo\n", "bar"]</i><p>Listed as a gotcha, but it only occurs on an old version of Ruby (1.8). Nowadays, it'll work like so:<p><i>Array("foo\nbar") # =&#62; ["foo\nbar"]</i>

Browsing 69 slides was painful in Mobile Safari, but the big picture message + simple example is good: encapsulate code to improve readability (it's not just for classes in OOP).<p>The modeling of: writing prose &#60;-&#62; writing code<p>reminds me of: micro air vehicles flying &#60;-&#62; birds flying.

I've been thinking about exactly this problem. I'm now re-organizing my unit and integration tests into some coherent order, which I hope will help refactor to a better code base.<p>Any thoughts out there on how to organizing tests to support "confident code"?

Click or use arrow keys to navigate.

This might be heresy, but how could one do something similar in Go? Would it be worthwhile?

So removing error handling makes code "confident"?<p>There were some other good points in there about encapsulation, but communicating to users properly trumps looking pretty to programmers.

I <i>really</i> like the basic idea, but there do seem to be a few potential drawbacks.<p>(1) Performance. Coercing values that might have been the target type to start with is wasteful. Extracting secondary paths into separate functions is wasteful.<p>(2) Readability of non-primary paths. Extracting non-primary paths into separate functions might make them harder to follow. Error paths matter. They often demand greater diligence than the happy path, so sacrificing them for the sake of the happy path would be bad. The increased <i>length</i> of the code bothers me a lot less than that. Namespace pollution could also be a concern in larger projects. If the code is reused, great, but if it's single-use then this refactoring would be bad for maintainability.<p>(3) Complex recovery and variable scope. The cow example is fine, but a lot of real code has to deal with much more complex error conditions. This is not just a matter of what can fit on a slide; handling more complex errors introduces <i>fundamentally</i> different issues. Often you need to know how far you got in order to unwind properly, and that information is likely to be contained in local variables. In some cases this means you should nest functions more, but this also destroys the "narrative" structure plus look out for points 1 and 2. In other cases it's just not even feasible, so splitting the error path into a newly-created function means having that function parse what really should remain <i>local</i> variables.<p>The idea of preserving narrative flow is good. The conceptual framework of input, action, output and error is immensely useful. Given these caveats, though, identifying one style as "bold" and one as "timid" is just an immature appeal to emotion. It's not timid to write efficient code, or code that respects separation of concerns. It's not bold to write code that preserves its own simple structure at the expense of everything around it. This could be framed as selfish vs. cooperative code, making the opposite emotional appeal, and be just as valid. The goal is to write <i>clear</i> code, and this is just one way that applies in some circumstances and not others

fantastic

Really sucks it do not work for ipad..

I don't understand is Ruby still good for programmers or Cowsays: "no it is not" ?

&#62; Windows &#62; Sorry :-(<p>And that's what happens when your programming language does not have a decent deployment ecosystem.