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.
Reflections on Programming
11–16 of 16 posts
Re: Reflections on Programming
#12[deleted]
Re: Reflections on Programming
#13The 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?
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+:
Re: Reflections on Programming
#14I'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?
Re: Reflections on Programming
#15> 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/ICPC20…
Nice article!
Re: Reflections on Programming
#16I'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…
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.