from Hacker News

Writing code that works on first go

by chegra84 on 7/10/11, 8:15 AM with 24 comments

  • by qntm on 7/10/11, 11:21 AM

    I instinctively distrust code that works first time. I advocate error-driven development.

  • by dustingetz on 7/10/11, 2:55 PM

    1. an ide/language with really good static analysis 2. aggressively minimize codebase complexity

    done. when my code doesn't work the first time, and i'm writing in a static-typed language, it's usually due to high accidental complexity in my code or code i interface, requiring me to keep too much context in my head, causing logical problems and problem states to be non-obvious.

    stupid errors like writing an if statement wrong, is sophomoric. "most common errors" really means avoiding mutable state & leaky abstractions[1]. i do think the OP gets this, it just doesn't come across too clearly.

    [1] nostrademons of HN, "how to become an expert swegr" http://news.ycombinator.com/item?id=185153

  • by gtani on 7/10/11, 1:27 PM

    Should generate some debates, depending on if you're from the static/dynamic typing, IDE vs. wetware, TDD or not, etc camps.

    3. If you use IDE's or vim/textmate/emacs and a decent language plugin, you'll argue the IDE should match braces and insert skeletal control structures.

    5. Self-contained function, so no side effects, isn't that part of the definition of functional purity in them "academic languages" (heh)?

    6. How do you define edge and corner cases? Is there something like QuickCheck for your dev environment?

  • by jaxn on 7/10/11, 1:50 PM

    I think it would be great if there was a way to easily capture my "most common error categories".

    Years ago I got bit a couple of times by assignment instead of comparison errors (i.e. if(x = 1) instead of if(x == 1))

    I noticed a pattern and made a conscious to always put the variable last in comparisons, so for years I have written if(1==x) so that the compile would fail if I wrote if(1=x).

    Having a way to see my most common errors would give the opportunity to look for similar error-proofing measures.

  • by kstenerud on 7/10/11, 3:34 PM

    I'm far more interested in code that works when it ships than code that works the first time it's run.

    Code that works the first time it's run is magical, and therein lies the problem: Magic code is untested and unproven code. It offers a false sense of security, which is why it fills experienced developers with a sense of dread.

    Until you prove that code's correctness (such as with tests), it is almost certain that it has nasty bugs in it that your initial successful run haven't uncovered. So what does having it work the first time give you? Bragging rights, maybe, but nothing of any real value to shipping code.

  • by chopsueyar on 7/10/11, 5:25 PM

    Non-IDE Python programmer comments, please?