
Reflections on Programming - koblenski
http://sam-koblenski.blogspot.com/2016/03/reflections-on-programming.html
======
agentultra
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!

~~~
Flemlord
Do you have any recommendations on how to write formal specifications?

~~~
agentultra
Short answer: try starting with TLA+.

I'm working on this. My colleague, who is mentoring me, is the one who's
finishing his PhD in software engineering. It's his guidance that has helped
me so I don't have a good answer for how to teach yourself yet. We're working
on a project to create specifications for Openstack and are learning a lot by
working together on how formal specifications could be taught to hackers and
developers with no formal mathematics training, etc.

If you want a brief introduction to the ideas try some of Leslie Lamports
talks on TLA+:

[https://www.youtube.com/watch?v=iCRqE59VXT0](https://www.youtube.com/watch?v=iCRqE59VXT0)

[https://www.youtube.com/watch?v=-4Yp3j_jk8Q](https://www.youtube.com/watch?v=-4Yp3j_jk8Q)

------
groovy2shoes
> 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...](http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf)

~~~
kzisme
Nice article!

------
JamesHurburgh
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.

------
randcraw
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?

~~~
collyw
In the last 6 months I have inherited two codebases. What bothers me more than
any of this is the unnecessary complexity people have introduced. Complex code
for doing very simple stuff. Way more database calls than are needed. Joins in
the app. Python written in the style of Java. Loads of loops that could be
eliminated with a bit of thought up front and a marginally different design.

Instead everyone gets caught up worrying about small stuff like this. Sure it
makes a difference, but in the grander scheme of things the architecture makes
a far bigger difference.

------
dcw303
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.

------
tzaman
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 :)

~~~
Shamiq
hah -- i found the same result with gofmt, golint, and go vet

~~~
douche
Agree 100%. JetBrains tooling is fantastic for enforcing consistent style. The
little squiggles and red and orange marks compel people to fix their shit, the
way spellcheckers do. To the point that I almost want to pay out of my pocket
for subscriptions for my coworkers.

------
bsder
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.

