Live data from Hacker News

Reflections on Programming

sam-koblenski.blogspot.com

1–10 of 16 posts

Re: Reflections on Programming

#2
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 :)

Re: Reflections on Programming

#3
post #2

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 a…

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

Re: Reflections on Programming

#4
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, 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.

Re: Reflections on Programming

#5
> 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...

Re: Reflections on Programming

#6
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!

Re: Reflections on Programming

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

Re: Reflections on Programming

#8

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 met…

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

Re: Reflections on Programming

#9
post #3
post #2

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 a…

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

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.

Re: Reflections on Programming

#10
post #8

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 met…

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

If they fall into the formal specification category, I've found Writing Effective Use Cases by Alistair Cockburn to be very helpful.
Post reply on HN