Slashdot Mirror
Ask Slashdot: What Do You Consider Elegant Code?
lxrslh writes: "Since the dawn of computing, we have read about massive failed projects, bugs that are never fixed, security leaks, spaghetti code, and other flaws in the programs we use every day to operate the devices and systems upon which we depend. It would be interesting to read the code of a well-engineered, perfectly coded, intellectually challenging program. I would love to see the code running in handheld GPS units that first find a variable number of satellites and then calculate the latitude, longitude, and elevation of the unit. Do you have an example of a compact and elegant program for which the code is publicly available?"
or is the OP requesting us to hunt down a piece of code that fulfills his project specs (and does it elegantly, gosh darnit!)?
Is the OP's real name Tom Sawyer?
A lot of "real world" code out there has not been designed, it has grown, and that's part of the problem. Think of cities that have grown (London?) rather than be designed according to some grand master plan (New York?) and major reengineering exercises need to be undertaken (in the case of London, as one example, sewage pipes were fitted in underneath). Inevitably there's some shortcuts taken or real reasons that you could not quite do the best job.
Codewise, the oldest running code probably lives in the banking system or the telephony system. Typically code that has grown over time and can't just be shut down for an upgrade -- "what do you mean close the bank for a week?". Now whatever code runs there has been kept running (bodged?) for decades, but pretty it probably isn't.
Just like everyone else
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
The common definition for elegant code is. "Anything not written by someone else."
In general code tends to be an ugly patchwork until you refactor it, introduces a couple of bugs, fixes the bugs and ends up in the starting position. The big change is that you now realize why the "ugly patches" were an elegant solution to the problem.
Or to phrase it differently; elegant code is code that has enough comments to explain why it isn't possible to make it simpler.
I consider code elegant if I can read it and understand it on the first try, personally.
Most code will not fall into the "elegant" category. The reason is that real-life software has to deal with exceptions, language crocks, patches/modifications and bug-fixes. It is also subject to the constraints, limitations and ugliness of whatever it has to run on and interface with (no program is an island entire of itself Every program is a piece of the continent, A part of the main() [ John Dunne] ).
Therefore the only place you'll find elegant code is in a book about algorithms, where the idea is presented in isolation and not subject to the practicalities of real-world environments
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
To me elegant code is code that has constant execution time, is readable at a glance and accomplishes it's function with little to no side effects. The last part seems to be almost impossible for most modern programmers, understandable when they never drop any farther than an abstraction on top of an abstraction.
IMO elegance comes with simplicity and duffs device actually makes the simple fairly complex, at least from a syntactic point of view. Mind you, compared to the unintelligable contorted rubbish calling itself C++ that I've had to debug over the years its a masterclass in clarity. Anyone who suggests building a framework for any project that is going to take less than a week should be shot on the spot.
Is this a joke? The reason Duff's Device is no longer any faster is because the modern compiler is able to optimize properly.
New code is always elegant at first. But invariably it doesn't work properly, and by the time you have got it to work, it's no longer elegant.
Maybe you've been lucky enough to have that once in a lifetime great teacher. The kind of teacher who somehow explains stuff in such a way that everything makes sense to you; things follow logically from one another and it all seems obvious when he explains it. (And you may not even realize it until he falls sick and the substitute trying to explain the exact same stuff leaves you confused and baffled.)
Elegant code has the same property of apparent obviousness. You read it and just nod because it makes sense and flows logically. There isn't one single way to achieve this, of course. It's not about functional vs. imperative vs. object oriented, but how you employ them for clarity.
Needless to say, such clarity is a very hard property to achieve, and a lifetime of experience will only let you approach it asymptotically. It's still worth the attempt, though.
-- B.
This sig does in fact not have the property it claims not to have.
I've written code that computes a CRC. It's been done before. The naive/reference implementation works but isn't fast. The optimized version, and how the heck that came about from the naive implementation to those magic few lines of code, looks nothing like it. Now rather than you glazing over "what the?", I figure that *if* you have to overhaul this code, you'd like to know *why* this code looks like it does. So I explained why. In the code. In a full page of comments.
Fail. Elegant != Complicated.
This is a common fallacy which makes many programmers think they are great but they are really are abysmally bad. Code has to be readable! Here is something that gives the idea:
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. --Tony Hoare
Most programmers considering themselves "good" fail this test and go for the second option.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Manual optimizations such as Duff's Device usually prevent the compiler from doing automatic optimizations because the effects of the code becomes obscured.
The GPS code I've seen was horrible and I worked for one of the major GPS players for several years. Originally written in FORTRAN and later automatically converted to C. Utter crap basically. The mathematics behind GPS is really interesting and quite involved. The implementations are crap.
Saved me from writing the same thing. The GPS code I've seen, written by engineers and not programmers, was an incredibly hacked-together, barely-functional set of kludges to implement a lot of very elegant mathematics.
For another example of a well written large project, try gcc.
Another example that's at least as elegant as gcc is OpenSSL.
Code written to do one thing is inherently elegant.
No code ends up ever having to do one thing.
The job of requirements gathering is to determine what are the constants and what are the variables. In the case of, say, GPS, the constants should be the protocol of the satellites, the max and min # of sat's that can be found at any given time, the grid representation of the earth, and the system clocks.
Nice and easy, right?
Now change all of those to a variable: you have satellites speaking to you in different protocols based on their age. You end up with only one sat connection so no triangulation due to mountain or building blockage. The grid representation of the earth is inherently distorted at the north and south extremes (and whenever you're above 5,000 feet). Oh, and the you forgot to time-distort your own clock for the rotation of the earth, so a tiny offset is being caused by General Relativity.
Suddenly code that was nice and simple is now full of ifs and switch loops and complex adjustments and bits of guess work and comments that say "oh, well, we'll just have to ignore that last part...but we'll only be off by 30 feet or so".
The first bug in software happens when something that was presumed in the requirements to be a constant has to be changed into a variable. Every bug that follows is a result of trying to fix that first bug.
Because of that requirements problem, no working production code can ever be elegant.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
It's not elegant because it's a dirty optimisation taking advantage of two inadequacies of C: The horrendous fall through behaviour of switch statements, and the lack of a requirement for proper nesting of control blocks.
The original code is far more elegant than DD.
Put it another way, the only reason for using DD rather than the original is that it was quicker on non-optimising compilers. Not that it was graceful, nor stylish, nor simple.
The fact that it's slower than the original code now makes it even less of a qualifier. It's now an optimisation failure. Something that needs to be removed to optimise.
Wish I had mod points. In seems to be a badge of honour for some coders to make their code as obfuscated as possible. I'm not sure who they're trying to impress but it sure as hell isn't the poor maintenance coders a few years down the line.
I strongly disagree with this. While I admit that elegant code can have ugly portions refactoring will often be an improvement but the trick is to learn when refactoring will help and when it will be a waste of time. The worst programmers I know are the ones who say that "I don't have time to go back through my code". I have cleaned projects where the original coder did the same thing three different times or reinvented the wheel when there were better libraries. In fact, I have been also guilty of this and even in my own projects I have come across places where the requirements changed out from under me mid project or I simply see better ways of doing things as I gain experience.
Elegant code:
1 Handles errors gracefully
2. Only reinvents the wheel when there is a measurable benefit in doing so.
3. Has consistent naming conventions.
4. Has comments around ugly code explaining why it is ugly.
5. Compiles (or runs if interpreted) without warnings.
I've been coding for the fun of it again in my spare time, and have a fair bit of code up on GitHub now. I've only been seriously using C++ for the last couple of years, and you can see a bit of a progression from my early code (fr_demo) to more recent code like the data library and resumetron. Stuff like cppxml which I use frequently gets updated more often than the old demo code.
I particularly like my factories. I have a relative going through a CS program right now and he's had some questions on a couple of his assignments and got a look at a piece of code with data readers provided by his professors. They always look like C code that was written 15 years ago. I know this because I also very recently was digging through some C code that was written 15 years ago. I like to think they're doing that on purpose, but they're not. So his introduction to design patterns could have been a nice clean data factory that requires three lines of code to write, but instead it's the singleton pattern, which every design review board on the planet will now reject immediately after the word leaves your mouth, whether it's actually justifiable or not.
One of these days real soon now I'm going to need to go back and replace all my std::string throws with std::logic_errors or other appropriate std::exception errors, and I'm kicking around the idea of building up a simple rest server around my old socket server code one of these days. That sounds like fun to me!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
...I'm not sure who they're trying to impress but it sure as hell isn't the poor maintenance coders a few years down the line.
I write simple code. I am primarily a C/C++ coder and in the "Obfuscated 'C' contest", I wouldn't even make the cut.
My code was described as very "simple" in a patronizing tone. My code works, has very very few bugs, it is done on time, and looking back at it after year, you can see exactly what it's doing - even without reading the many many comments.
I was treated as the dullard of the team. It's like if you don't use all the tricks and shortcuts, somehow you don't really know the language that you are programming. And if your code is too easy to understand, then you are not as smart or good.
I started in this business in 1992 and I have never been in a shop that did not have the attitude.
Many moons ago I refactored a complex function by a much respected 'Master Programmer'. "It's going to take you a good few years before you're at his level", they told me. After I had finished refactoring his function, a page and a half of heavily nested if/else statements had boiled down to a single CASE statement, 4 lines long, doing the exact same thing that his original code did.
In my book, this guy wasn't a Master Programmer at all. He overcomplicated things. His code was unmaintainable to anyone but him - and evidently he had a pretty hard job maintaining his own code.
Elegant code is code that correctly solves a particular problem in the simplest possible way. Bonus points if minimal CPU/Memory resources are used to achieve that.
It's just optimizers all the way down.