Of Bugs and Coding Styles

A weekly podcast with Cliff Click talking about all things to do with programming, programmers and computer performance.

A discussion about bug rates and coding styles.

 

6 thoughts on “Of Bugs and Coding Styles

  1. Thanks, Cliff! I now feel better prepared to defend my favoring of the ? : operator over a multi-line if/else.

    I like your description of productivity on your team being a = 2b, b = 2c, and so on, which is different from the 10× developer we often hear about.

    I look forward to listening to more episodes!

  2. Great Podcasts so far…looking forward to the future
    Any chance you could notify folks on twitter when you post new ones? I’d like to keep following… (& dont have any apple products)

  3. Very interesting podcast so far, hope you keep making these.

    I would be interested to hear if you have any information on bugs showing up when people are having to interfaces with other people’s code vs simply working against something that they have written. I personally find that when I make some slightly incorrect assumption about how a library is a large source of bugs.

    • Yeah – if you don’t trust your understanding of the foreign code you are calling – “assert” the crap out of it first (both pre- and post-conditions). Ignore the assert speed, and get library spec right first – then yank the “too slow” asserts later. Run a largish test suite on your asserts. You should have a collection of failures, some of which will be fast & easy to debug. Beats getting failures “later” (post library call) and trying to back track them down to a subtle mis-understanding of the library.
      Cliff

  4. For the last 5-7 years the advise for C++ coding style is “use clang-format”. You can write however you want, but run a single command before check in so that everyone else does not have to re-train their eyes for a different code-style.
    Well clang-format is primarily about spacing but that is the first thing people notice.
    Camal -vs underscore – yeah, a simple script can fix it too.

    • Same problem as before though; after you clang-format, you’re not coding in your own favorite style. Suppose I’m working on a largish new feature; it’s going to take a month. Once a week I merge master into my branch (that’s actually really low merge rate, I tend to merge a lot more often). Do I clang-format my code before each merge? Then right away I’m coding in the Company Default Style instead of my preferred style – and slowing down my progress on this large new feature. Do I only clang-format once before the push? Then every merge conflict I end up resolving involves my coding style vs clang-format, and pretty soon I pick up lots of “white space fluff” in the merges. Being a Largish New Feature, it’s probably got bugs, and I’m probably working on this code live and in master for a few months yet (or maybe years…). I’ve worked in this kind of environment before, and I’ll claim it’s slightly-different-and-not-better than a globally enforced style.

Leave a Reply

Your email address will not be published. Required fields are marked *