Join the DZone community and get the full member experience.
Join For FreeEvery so often someone writes an article talking about what great code,
or beautiful software, is (or insert some other superlative.) And,
surprise! surprise! It always looks like just like the author's code!
It's funny how that works out.
Let's take a more interactive approach today. I'm going to present a few choices and support them a bit. Then I'll ask you to tell me why I'm right or wrong, or if I'm simply asking the wrong questions.
Useful
Code that doesn't help anyone is just a useless exercise... or is it? Can a detailed and intricate bit of code written for a coding kata, an exercise, be useful? Or is it just thrown away?
What if the code itself is perfect, well written, in fact a great piece of work, but no end user finds it acceptable or usable? Is it still great code?
That depends on your definition of "great", doesn't it?
Automatically Tested
The longer I'm in technology the more I think this is a basic skill set. And I'm not talking about unit tests either. They have their place, but automated testing is much more than just unit tests.
Sometimes they're testing how five objects interact. Other times they're package level tests. Still overs are complete integration tests.
The goal is to have a test suite that provides sufficient safety to the developers, and have it run after every single code change. This size test suite won't be run locally by developers, so we use a continuous integration server (or a collection of them!), to run these tests after code is committed to a source code management system.
The value of having your own code tested after you edit is huge. Having that test run when your co-workers edit your code is invaluable. And having these tests in place when the code moves into production support, and later maintenance mode, completely changes the game.
Small
No matter how large the entire codebase turns out to be, I like small routines, small methods, and small classes. Each routine, and each class, can be easily tested and fairly easily understood. This reduction of cleverness drives down the time needed to write the code, debug the code, and later, support the code.
Simple
I've seen lots of clever code. It's fast, when it runs. It shows us how smart the developer was. It also shows us that he or she didn't take the time to finish the job. We start with nothing, then build up the code, often reaching very clever solutions. But then only the truly clever go one step further and break it back down to its component pieces, making it simple again. The insanely brilliant skip the middle step and go straight to simple.
Understandable
Are you the only one who can read and understand the code? Then it's bad. It might be the way you wrote it or it might be the problem domain, but I strive to create code that's human digestible. Computers are always running faster... my laptop has four CPU cores in it! But the human brain is still slow for this type of work, so let's be sure to optimize for the human brain (where it makes sense). Writing code that you or your coworkers can't read in a year isn't great code.
So what's your definition?
Let's take a more interactive approach today. I'm going to present a few choices and support them a bit. Then I'll ask you to tell me why I'm right or wrong, or if I'm simply asking the wrong questions.
Useful
Code that doesn't help anyone is just a useless exercise... or is it? Can a detailed and intricate bit of code written for a coding kata, an exercise, be useful? Or is it just thrown away?
What if the code itself is perfect, well written, in fact a great piece of work, but no end user finds it acceptable or usable? Is it still great code?
That depends on your definition of "great", doesn't it?
Automatically Tested
The longer I'm in technology the more I think this is a basic skill set. And I'm not talking about unit tests either. They have their place, but automated testing is much more than just unit tests.
Sometimes they're testing how five objects interact. Other times they're package level tests. Still overs are complete integration tests.
The goal is to have a test suite that provides sufficient safety to the developers, and have it run after every single code change. This size test suite won't be run locally by developers, so we use a continuous integration server (or a collection of them!), to run these tests after code is committed to a source code management system.
The value of having your own code tested after you edit is huge. Having that test run when your co-workers edit your code is invaluable. And having these tests in place when the code moves into production support, and later maintenance mode, completely changes the game.
Small
No matter how large the entire codebase turns out to be, I like small routines, small methods, and small classes. Each routine, and each class, can be easily tested and fairly easily understood. This reduction of cleverness drives down the time needed to write the code, debug the code, and later, support the code.
Simple
I've seen lots of clever code. It's fast, when it runs. It shows us how smart the developer was. It also shows us that he or she didn't take the time to finish the job. We start with nothing, then build up the code, often reaching very clever solutions. But then only the truly clever go one step further and break it back down to its component pieces, making it simple again. The insanely brilliant skip the middle step and go straight to simple.
Understandable
Are you the only one who can read and understand the code? Then it's bad. It might be the way you wrote it or it might be the problem domain, but I strive to create code that's human digestible. Computers are always running faster... my laptop has four CPU cores in it! But the human brain is still slow for this type of work, so let's be sure to optimize for the human brain (where it makes sense). Writing code that you or your coworkers can't read in a year isn't great code.
So what's your definition?
Topics:
Opinions expressed by DZone contributors are their own.
Comments