Slashdot Mirror
Ask Slashdot: What Makes Some Code Particularly Good?
itwbennett writes: When developers talk about what makes some source code particularly 'good,' a handful of qualities tend to get mentioned frequently (functional, readable, testable). What would you add to this list?
Not being .NET and Not being Java would be my tops.
For newly written code, things like readability, testability, and maintainability all can come in to whether it is "good" or not
For legacy stuff, Good code is code that works. Who cares how easy it is to read or test as long as it works?
The second one should also include "immutable". If it's hard to understand it will evolve easily to non working, and time spent on improvements can start to creep up very fast.
I have worked in very clever, solid code, but not easy to read. It was then maintained and extended by average, but competent programmers down the road, and turned into a big mess, only because it was so hard to understand.
In my experience, good code is easy to read, above all. That will make it easy to extend it coherently, find bugs and stuff. Also, if it doesn't work OK, it's easy to find out why. The single metric that saves time, money, and improves quality down the road is readability. Eveything else should be suject to that.
And, about the last point in the "article", "efficient", it's nonsense. Premature optimization is the root of all evil. You should _always_ follow the second rule of optimization (see http://c2.com/cgi/wiki?RulesOfOptimization ).
Good code has documentation for knowing what it should do, and has unit tests to verify that it actually does that. If there are any problems good code can be modified to meet the (possibly changed) requirements better, while unit tests ensure the modifications do not make the code worse. Code which cannot be modified is not good code. It's that simple.
Their whole mindset still makes me want to puke.
Obfuscated crap. Techno-machismo teens playing games trying to get their code into the least number of characters and the least amount of memory. I've had to fix or test so much of this junk and it's still just plain stupid.
The *human* part of the system is what *matters* and that includes the code interface. First, I want comments not about *what* is happening. I can read that. I need to know *why* it was done, so I don't undo it, or I can do something different safely. Comments should be one liners, limited to "why" and sometimes "how".
If adding a variable aids readability, add the fucking variable! Shove all the results into a meaningful, readable variable name and then shove *that* into your function argument, not some long series of nested function. It's not the 90s. You don't have to save memory! Memory is there to make your code readable. Use it!
Ok, rant over. I'm going back to work now.
Please do not read this sig. Thank you.