Reflections on Programming

The thing that has changed most for me was recently discovering formal specifications and learning to think about how to model systems first before trying to code them. Seeing how wrong people can write binary search was pretty astounding.

It took quite a lot of things to go right for me to finally try it out but I'm glad I took the plunge. Writing specifications in plain human language is a good start but formal methods have shown me how sloppy my thinking is. It forces you to be rigorous!

I've been having to "unlearn" quite a lot but it's starting to turn around and coming back to where I was is going to be amazing.

10 years ago I would have scoffed and said you didn't need math in order to be a good programmer. I couldn't have been more wrong. If I knew then what I do now!

> I think snake_case is more readable than CamelCase...

It might actually be more readable. See Sharif & Maletic (2010) [0]. Unfortunately, like many studies of its kind, it suffers from a tiny sample size and various experimental flaws. However, I still think it's interesting, and I think this kind of research is very important---if only it could draw more funding!

[0]: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn...

I really think Hungarian notation makes code far more unreadable than any benefit it provides. You're assuming that the next maintenance developer also knows your flavour of notation. Do them a favour and just give your variables a human readable name that describes what it is.

I'm amazed that there aren't more discussions about code readability -- the judicious use of whitespace, the choice and conventions for variable naming (including plurals and uppercase vs lowercase to denote semantics other than classes), and the sundry other choices we routinely make. Like language choice (and hungarian notation), coding style has a big impact on code legibility and can greatly clarify the intended semantics.

I'd love to see a range of rigorous experiments that explore which conventions are more comprehensible and maintainable. It's curious that after 30+ years of software development, such practices seem to have been minimally explored, much less clinically assessed. I'm puzzled that we programming pros are satisfied with groupthink (like OOP), apocrapha, and unending religious debates.

So where's the 'engineering' in software engineering?

I mostly agree with the thoughts on testing, and agree with the principle that unit test overkill is not constructive.

I don't think 100% control path coverage is hard to achieve though. If done correctly, it should not require an excessive number of tests. If your methods are so convoluted that covering every path is complicated, you probably need to split up your code further.

I name my test methods like this: test<MethodUnderTest><Assumption><Expectation>, e.g:

  void testCalculateWithIncorrectFooIsNotValid()

Writing lots of tests that have ridiculous names is a code smell that I've overdone it on testing. Although this doesn't happen as much with statically typed languages, since the compiler does a lot of the work for you.

One of the hardest things for me is (or was) consistent styles, because I'd change something with every new project, and several projects down the line, everything was different.

Somehow I was too hard on myself (or should I say perfectionistic?)

But,... I found a cure :) Developing JavaScript (ES6) means I have access to all sort of tools and one of the best out there is Eslint. On top of that, I use AirBnbs rules and no more issues - all I have to do is take someone else's directions and be happy with them. No more styling OCD :)

I find that you should but basic tests in place, but you beef up tests where you find bugs.

You have to build tests to debug things, anyway, so you might as well put them in your test suite afterwards.