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 :)
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.
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.
> 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!
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'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+:
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?
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.
15 comments
[ 4.5 ms ] story [ 50.3 ms ] threadSomehow 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 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:
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.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...
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'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=-4Yp3j_jk8Q
You have to build tests to debug things, anyway, so you might as well put them in your test suite afterwards.
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?
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.