Ask Slashdot: What Do You Consider Elegant Code? 373
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?"
Duff's Device (Score:5, Informative)
Re: (Score:3, Informative)
Uh... that Wikipedia article shows 3 lines of code, which it describes as "straightforward":
Then this reference implementation of Duff's device:
Re:Duff's Device (Score:5, Funny)
Personally, I blame the compiler for failing to optimize properly.
Re: (Score:2, Insightful)
Is this a joke? The reason Duff's Device is no longer any faster is because the modern compiler is able to optimize properly.
Re: (Score:2)
Re: (Score:2, Insightful)
Manual optimizations such as Duff's Device usually prevent the compiler from doing automatic optimizations because the effects of the code becomes obscured.
Re: (Score:2)
According to the reference, the reason for the speed improvement had to do with the vastly different CPU architecture and specifically with getting more cache misses due to an increase in the size of the code base because of the unrolled loops.
It seems rather silly to imply that Duff's device is no longer elegant merely because it does not apply to current CPU architectures.
Re:Duff's Device (Score:5, Insightful)
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.
Duffs Device is clever - its not elegant (Score:5, Insightful)
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.
Re: (Score:2)
Time. Good point. Many building architects defend bad designs with, "but that's all the time we had."
Either the original developers have time to iterate to a cleaner design, or the maintainers have to do it, or the original developers had lots of experience with similar frameworks that they already have better designs in mind—acquired over time.
Re: (Score:2)
I don't think that's what he meant. I think he says that anybody who manages to add complexity to something simple and straightforward (a project that would only take a week to do) by adding "beautiful" layers that provide abstractions for the sake of abstraction, should be shot. Personally, I would happily set fire to the remains after the firing squad had its turn.
Re: (Score:2)
Aha, right you are, thanks. Yeah, funny thing about abstraction, somewhere somehow, there still has to be an implementation anyway.
Re: (Score:3)
Re: (Score:2)
Look at the examples from that article:
Compared to Duff's optimization:
Re: (Score:2)
To me, elegance at code level means succinct and readable code. Optimizing for performance usually comes at a lower level of readability.
Therefore, first write the code in the most elegant way.
Then, write an optimizer that optimizes that code. Of course, the optimizer itself should be elegant, but it need not be efficient.
Re:Duff's Device (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Re:Duff's Device (Score:5, Insightful)
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.
Re:Duff's Device (Score:5, Insightful)
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 am one of those guys (Score:5, Insightful)
...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.
Re:Duff's Device (Score:4, Insightful)
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.
Re: (Score:3)
Linux kernel (Score:3)
Re:Linux kernel (Score:5, Insightful)
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.
Re:Linux kernel (Score:5, Insightful)
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.
Re:Linux kernel (Score:5, Insightful)
I've been coding for the fun of it again in my spare time, and have a fair bit of code up on GitHub [github.com] 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!
Re: (Score:3)
1 Handles errors gracefully.
This statement always hits me as mind numbingly stupid. In general try / catch and other error managing statements are for the lazy that don't want to understand the environment and inputs well enough to write the proper code to manage them. You want rock solid code that will last for years, eliminate the errors, don't "handle them gracefully". The only exception to this rule should be when the native environment forces it upon you or there is a lack of some proper check "doesThisReallyExist()".
By errors I meant where paths and files don't exist, the user or external software sends bad info or someone runs or the machine runs out of resources. Case in point: someone edited one of our databases in a place I used to work and some software crashed hard when it grabbed a NULL value from the database leaving me to check the core dump to discover the problem.
2. Only reinvents the wheel when there is a measurable benefit in doing so..
I learn more reinventing the wheel and there is no substitute to working with code you are sure of and know how it's going to perform.
I agree with the rest.
I can see wanting to learn.. I can't see duplicating system libraries in a project. Some libraries (Libc in particular) have whole groups of progr
Re: (Score:3)
You want rock solid code that will last for years, eliminate the errors, don't "handle them gracefully".
Good luck writing code that eliminates the possibility that a read on a filehandle produces an error, so you no longer have to handle errors at all.
I learn more reinventing the wheel and there is no substitute to working with code you are sure of and know how it's going to perform.
It's great to learn, but you shouldn't be putting your homework problems into production software.
There is a substitute for using only your own code that you are "sure of how it's going to perform". It's called using a good framework and libraries. If you aren't going to trust any 3rd party code, why not write your own compiler and kernel too? It pretty ridic
Re: (Score:2)
Code quality in the Linux kernel varies a lot per individual driver or subsystem. Many interfaces are under-documented: you have to read the implementation code and make an educated guess at what the intended interface was. And a lot of the error handling paths contain bugs, since those are rarely exercised when testing manually.
The Linux kernel might seem elegant if you just read the code superficially. Once you start making changes and have to know exactly how it works, you'll see the problems that many p
Is this a request for optimal code design... (Score:4, Insightful)
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?
Re:Is this a request for optimal code design... (Score:4, Insightful)
The request is oddly specific.
It might be more prudent to ask for particularly nice before- and after refactoring examples in general.
I love the elegance of object oriented parser frameworks (disclaimer; I've made several myself), but that elegance is rather in the model than the code.
Elegance purely in code I can only really remember seeing in small functions and snippets. Mostly elegance seems to be in the structure and interaction between functions or objects.
Re: (Score:2)
The request is oddly specific.
Yes. Very odd...
Almost like a code request.
The correct thing to do would be to find one then add a very sneaky flaw. Find out if all he really wanted was to "read" it.
Re: (Score:2)
It might be more prudent to ask for particularly nice before- and after refactoring examples in general.
Seconded!
I once saw a Java class with pages of complex multi-threaded code to update the horizontal offset of the ticker in a GUI. Not counting the usual minimum content of a class file, I replaced it with a single line along the lines of "return velocity * getCurrentTime();". So satisfying! 8)
Re: (Score:2)
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?
OP Here: I am a retired Assembler 360 programmer. I have no project needs or other reason for my specific example, which was merely an example of what I suspect/hope is an elegant program. I could be wrong about that. Feel free to discard your understandable cynicism.
Re: (Score:2)
Ha HA! Ya got me. .
At this stage in the game I don't know where the cynic ends and the human begins.
"Probably at the asshole," a voice whispers in my ear.
Re: (Score:3)
The BAL Macro language could do things that C++ template functions can't. You could test *all* of the attributes of a parameter, from datatype through number of characters in the name, and vary the generated code accordingly - amazingly powerful levels of abstraction when used properly.
Re: (Score:2)
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?
Do we have to pay to join in?
Writing Code is like Explaining Things (Score:2)
I like to think that if code is 'elegant', it can be read well after at most after brief explanation of how the algorithm is supposed to work, because code alone is sometim
elegant = self-explanitory (Score:2)
exactly my thoughts as well.
all "code" is symbols arranged to communicated **instructions** to a machine
it's all instructions...the variation is the way the instructions are delivered
knowing this, and having some experience coding, elegant code will be understandable to even novices once the basic "language differences" are learned
Re: (Score:2)
Writing code can be like explaining something or teaching. You can give an explanation that is logically correct but difficult for a human to follow. Programmers tend to neglect this in their code because it can be difficult to construct something that reads well and even if it doesn't read well, it can still be executed by a computer.
I like to think that if code is 'elegant', it can be read well after at most after brief explanation of how the algorithm is supposed to work, because code alone is sometimes difficult to interpret.
Similar to my thoughts. There are levels of elegance. The minimum requirement is that it does what it's supposed to, that something is non-trivial, and the code is fairly easy for anyone familiar with the language to understand. Better is when it does all that without any prior explanation of what it's supposed to do. Even better is when the something it's doing is actually quite complex, but still easily understood.
And then there's just plain awesome, where it uses a language feature that the reader ha
Knuth's TeX and Metafont (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Think of cities that have grown (London?) rather than be designed according to some grand master plan (New York?)
I've never been to London, but I work in NY. It's almost the exact opposite of what you're saying, or maybe the middle ground that you didn't cover. Someone designed it to a master plan.... a long time ago. And then it grew. Nowadays I joke that if you're designing a city and your major highways look anything like NYC, it's time to fire the designer.
Re: (Score:3)
London has existed for over a thousand years. It has just grown organically. All recent services (such luxuries as underground, trains, ringroads, mains water, electricity, sewers, communication lines) have been retrofitted on that base -- and it shows. The roads are the wrong size for the amount of traffic -- trains clash and are overfull, high rise offices are planned but foundations have to carefully avoid all the t
I write spaghetti code (Score:5, Insightful)
Re: (Score:3)
Code I consider 'elegant'. (Score:5, Insightful)
Re: (Score:3)
I consider code elegant if I can read it and understand it on the first try, personally.
This is a good barometer.
When I write code, my goal is to create an accurate design with the proper abstractions that will make the complex business problem look like it was trivial to solve. The easier that I made my job look, the higher the quality of my deliverables, in my mind. The next person to look at my code should say, "Of course he solved the problem that way. I would have done the exact same thing."
By the way, given the sheer volume of WTFs I encounter, the next person to look at my code probably
Re: (Score:3)
Some engineers consider code "elegant" if it's factored to the smallest possible form, which generally means all repetition possible is factored out.
But such code has at least two problems. First, is that it may not be easy for a good portion of developers to read and understand. Factoring out all possible duplication often results in a lot of indirection (reference levels), and indirection can slow down and complicate reading because you have lots of small parts referencing (using) lots of other small part
Elegance only exists in textbooks (Score:5, Insightful)
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
Re: (Score:2)
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.
And those damn users. I can write what I (and seemingly others) consider "elegant" code. But that's usually only possible down in the bowels of a microprocessor where you have known constraints and no meat bags randomly typing shit at you that you have to parse and decipher and then present a myriad of exception messages back to, etc., etc.
Re: (Score:2)
Re: (Score:2)
Yes, but try to explain that to a manager, or to a user!
Re:Elegance only exists in textbooks (Score:5, Insightful)
At the data / object model level, there are good real-world examples of elegant coding. At this level, elegance affords the ability to make smaller changes or bug fixes without having to resort to major refactoring or adding a lot of messy code in many different places in your program. At this level, elegance also works to isolate the overall program from ugly interfaces / APIs.
Re:Elegance only exists in textbooks (Score:4, Insightful)
And maintainability. People often forget that one.
I once had a co-worker who wrote a component he thought was elegant, because it had a nice lovely modelling and abstraction and matched how he thought the problem should be solved.
The problem was, his solution was rigid, brittle, and kinda wrong. The things he turned into elegant objects didn't behave that way, and the things he didn't were the actual meat of the problem.
Every time he had to fix a bug or add a change, he spent time trying to understand how his code worked, where he'd have to make changes, and then bitching about how the change violated his nice 'elegant' code.
On another project, he was writing a component which consumed stuff from a component I and another co-worker had built (they were built concurrently).
By the time we were ready to do integration testing, his nice elegant code had been built on the assumption we would implement all of the semantics for his part (which we couldn't possibly have known). He had structured his code in such a way as to be 'elegant' as long as the library he was using had behaved in a way that nobody would have modeled unless it had been written to precisely implement his semantics.
And, again, his 'elegant' code was rigid, brittle, and wrong and had to be significantly changed to work with an interface he knew about in advance, because we'd agreed upon it before writing both pieces.
And if you start with a terrible object model and then write elegant code around that terrible object model, you get the exact opposite.
And then don't get me started on trying to make your 'elegant' code go faster because you've created more work with how you've structured your code.
Once had a coder tell me we shouldn't optimize because computers are Really Fast and we probably can't do any better. Then I threw away a large chunk of his code and replaced it with something which wasn't doing silly things, and we got a giant speedup.
Some people get so damned focused on writing what they think is 'elegant' code that it is neither useful to the task, well written, nor maintainable.
GPS code (Score:4, Informative)
http://www.gpstk.org/bin/view/... [gpstk.org]
http://www.rtklib.com/ [rtklib.com]
http://gnss-sdr.org/ [gnss-sdr.org]
Next time do your own google search.
Elegence? (Score:3)
I don't know if it counts as "elegant code", but I find it really useful that code is fully commented. Speaking for myself, it's useful to come back months or years after originally writing code, and knowing why I wrote such a routine the way I did, and what it does, making changes easier and quicker.
Re: (Score:3)
My rule of thumb is, "if the first implementation of this didn't work, and I had to change it, then it needs comments" on the principle that if the "obvious" solution turns out not to work, then the problem is not as obvious as I'd thought.
The original (Score:2)
The pinnacle of elegant code (Score:5, Funny)
http://www.ioccc.org/ [ioccc.org]
Re: (Score:2)
You may have been joking, but this one is fantastic: http://www0.us.ioccc.org/1988/... [ioccc.org]
It calculates pi by measuring the area of an ASCII circle, which is an incredibly direct encoding of the problem. Other than that there are two lines of supporting boilerplate and a couple of braces.
Minimise state (Score:5, Interesting)
You always have to keep in mind that code will be changed by serveal peopale, and your 'elegant' intention may not be understood or followed through by the next guy. So go for simple rules of thumb that not only keep your code readable and clear, but can accommodate future change while ramaining so.
My number one rule for keeping code both readable and robust is this: Reduce state.
I don't mean everything needs to be purely functional, but consider state a general liability to both correctness, readability, testability and maintainability. Less is more..
* Whatever state you have should be focused and serve to explain/model the actual problem domain, not just 'keep stuff for later'.
* Keep state as local as possible - most code is litered with instance variables that should have been locals and params.
* Just because an object _can_ bundle state with its functions doesn't mean it _should_.
* If it can be done in a static method and still make sense, do so.
Re: (Score:2)
In general, the best you can do in terms of simplicity is to write code that computes the result (e.g., the "current" observable state of an interactive program) from scratch at every instant. However, this would make the code needlessly slow. You are then forced to cache stuff, etc., and things become ugly...
Re: (Score:2)
True. But bear in mind that one shouldn't optimise early. So if one took the idea that state is bad, one could always compute the result rather than cache for the initial implementation. Then only cache where profiling indicates there's an issue.
Re: (Score:3)
Caching is an optimisation that does indeed introduce state, and all the problems that comes with it in full.
Like all optimisation, it constitutes buying performance in exchange for increased complexity (of some sort). The cost of complexity is high, and the tradeoff should be qualified by a solid cost-benefit anaylis, and by extension pertain to a demonstrably real performance problem.
That said, I certainly accept that 'true' changing state can be part of a good model, and I don't consider that caching. J
It's always elegant at first (Score:4, Insightful)
Re: (Score:2)
This depends. if there is no idiot manager breathing down the neck and allows the programmer to take the needed time to test, rewrite, test, rewrite... then the output is good code.
Loser managers that cut in half or worse in third the time it takes to actually write good code cause most of the horrid crap you see out there. I guarantee that everything written by Bioware is an unholy mess. The sheer number of bugs I see in every one of their releases means they dont care about good code, they care about th
Re: (Score:2)
Real developers ship. You are working for a business; you are not doing an academic study.
And here we have another problem. You think that good or elegant code means bug-free. It doesn't. There's lots of pretty code out there that doesn't do what it's supposed to do.
Elegant code is like a great teacher. (Score:5, Insightful)
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.
I'm a style prude (Score:3)
Code that explains itself (Score:2)
Elegant code is code you can look at and understand what its doing and then audit easily.
That is the real point of elegant code. You ACTUALLY know precisely what it is doing. No guess work. The best code can be understood with a casual glance and any mistake in the code stands out brightly because the pattern and elegance of the code is beautiful in its way. And any imperfection is ugly.
Elegant code is.... (Score:3)
Code that does the job in the simplest possible way. This means that the writer went through several prototypes before they settled on the code they liked instead of the normal..."it works SHIP IT!"
No obfuscated crap, it's clear simple and concise.
Read "Clean Code" (Score:3)
If you follow the principles and practices in Clean Code: A Handbook of Agile Software Craftsmanship: Robert C. Martin [amazon.com] you won't go far wrong. It also includes a worked through example of refactoring a piece of bad code into clean code.
My personal "law" (Score:4, Insightful)
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.
It exists, but you can't see it. (Score:2)
Unfortunately my employer thinks it belongs to the corporation, because they paid me something they call salary to me when I wrote it. They would not let me show it to you all. But this much I can tell you. The key to writing such wonderfully elegant code is to avoid exaggeration, stay away from bragging, and most importantly e
FORTH (Score:5, Interesting)
A complete highly extensible interpreted language with a built-in editor, macro assembler, etc in under 10k lines of code which did everything any modern scripting language does, except they all require at least 200KLOC to do it in.... This is the most elegant piece of software ever written, bar none. It isn't even a contest.
Elegant code is... (Score:3)
Elegant code is...
There are also some languages that I view as inherently elegant, and others that I consider not to be so. C, Python, and Ruby all allow breathtaking elegance in their own way. C with its spartan manner of managing the machine, Python with its ridiculously readable pseudocode-like syntax, and Ruby with its pure object system and powers of abstraction. On the other hand, some other languages like C++, Java, Haskell, Javascript, PHP, BASIC, and Erlang will never be languages that lend themselves to true beauty and elegance. All of those languages either have serious flaws, or they do not allow programmers to express their ideas eloquently in code. In a good language, your ideas should pop out as the most important thing, not the language itself.
Comment removed (Score:3)
Postfix (Score:3)
Fantasic example of code written in a procedural language (C) in an object-oriented way,with clear separation of responsibilities.
http://www.postfix.org/ [postfix.org]
The framework that Wietse created to structure Postfix is, from my perspective, a thing of beauty. I don't doubt that this has been done elsewhere, but Postfix is the first real example that I came across of a somewhat-large application structured in a very clean and understandable way.
Well worth spending some time perusing the code.
A tour guide w/"Programming Pearls" (not Perl) (Score:3)
His Programming Perls book does a nice job of putting interesting algorithms and design forces into context and helps the reader understand the pros & cons thereof. Part of the problem with just wandering around looking at things is you don't see the history and decisions that were made leading up to the result; understanding "what" isn't nearly as important as "why".
Also, the book isn't related the the Perl language; instead it uses Pearl as a metaphor for a small yet beautiful treasure.
Anyway, check out the Amazon reviews to see if it is worthwhile (I have no vested interest here; I just stumbled across this in a real book store some time ago and found it a satisfying read).
definition (Score:3)
I have long said I preferred elegant to clever code. When I get a phone call on Friday, at 16:15, or 02:00 some night, I want to leave on time, or go back to sleep that night, *NOT* spend hours figuring out how this bit of cleverness is broken, or how someone's "the code's more compact!" is suitable for entry in the Obfuscated C contest.
But to write elegant code, you need to a) know what you're trying to accomplish; b) tell your manager, or whoever, that no, you can't make that kind of major change without their $$$ signoff on a change to the schedule, complete with specing out the change, and its affects on everything else; c) having the time to write, test, and debug the code, and this does *NOT* include drinking a six-pack of Mountain Dew a day, and doing 80+ hour weeks.
Yes, I *have* had jobs like that. And 70+ or 80+ hour weeks result in a *lot* less "productivity" than the old 40-hour week (and try looking up where that number came from... the name Ford may surprise you in that....).
mark "as opposed to managers w/ MBA, who think that you can point and click a good system"
Re:Complete Spectrum Rom Disassembly (Score:4, Informative)
ftp://www.worldofspectrum.org/pub/spectrum/books/CompleteSpectrumROMDisassemblyThe.pdf
Re: (Score:2)
I don't recall it being particularly "elegant"....
Re: (Score:2)
Almost always better to use a loop, a good compiler can unroll the loop if doing so would be beneficial and unless your targeting a single specific device, what's most efficient will depend on the hardware - eg a large unrolled loop might be slower if the loop is too big to fit in the cpu cache, and the unrolled loops increase the memory usage of the program which may be detrimental depending on the speed and quantity of memory etc.
Re: (Score:2)
Agreed. I'll allow javadoc-like comments that help to document a public interface, but if you write comments to explain an algorithm, you're probably making a mistake.
Re:Comment your damn code (Score:5, Insightful)
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.
Re: (Score:2)
I was intentionally overstating it a bit.
There are of course cases where comments are warranted, and properly justified optimizations may be just such a case. The others also usually fall under the broader umbrella of "exceptions" to how things might normaly be done. Just don't use it as an excuse to make the code less clear than it could be given the perfomance constraints, and beware of premature optimisation, which is a prime cause of brittle and unreadable code, with frequently no real benefit to offse
Re: (Score:3)
As the purpose of comments is to explain *why* a part of code was created (and why it was written in that particular way), it not being executable shouldn't matter much, as completely repurposing a bit of code rarely happens. (Generalizing it yes; abandoning the original purpose of a routine or function is uncommon).
The best comments are those targeted for the programmer reading them, not the machine that must execute the code;
Re: (Score:2)
He probably means code that runs in O(1).
http://en.wikipedia.org/wiki/B... [wikipedia.org]
Re: (Score:2)
I suspect he meant "consistent".
Re:GPS? Are you kidding? (Score:5, Informative)
As someone who has a copyright assignment on file with the FSF for GCC and actually tried to write an implementation of the Visual C++ __declspec(thread) keyword for GCC-on-windows (i.e. proper OS-provided thread-local-storage support) and got lost somewhere deep in the code that actually converts the intermediate representation into assembler (I needed to do stuff to it so it would correctly access the thread-local-storage data when an access to a thread local variable was made) I question your statement that GCC is well-written, elegant or easy to understand...
Re:GPS? Are you kidding? (Score:5, Funny)
As someone who got lost somewhere deep in a single sentence (which consumed three whole screen-width lines) that spent nearly 100 words on a dependent clause (which itself contained two parenthetical clauses) before even getting to the subject (I was starting to wonder if there would be one at all) I question the value of your comments on the topic of elegance...
Re:GPS? Are you kidding? (Score:4, Insightful)
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 [peereboom.us].
Re: (Score:2)
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.
Yeah. If you want elegance, you should probably just go straight to the math. As soon as you put it into a computer with its pesky limitations of finite time and space, elegance goes right out the window.
Re:GCC? Are you kidding? (Score:2)
Re: (Score:2)
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.
Interesting. I can see that FORTRAN was once the computer language for mathematics, but it never occurred to me that GPS was old enough to be coded in it. But I see that GPS development started in 1973, and even then was based on some earlier work, so definitely during the time when FORTRAN was in common use.
Can't say I'm surprised that it tends to get ported rather than re-implemented. With something that's as complicated as that, with an implementation that has stood the test of time, better to stick with
Re: (Score:3)
I'll take a guess that readability is no more important in your code style than your prose.
Re: (Score:2)
Ironically, you could have done with some whitespace around that URL.
Re: (Score:3)
Does anyone else hate the conditional operator. It replaces six lines of code with one line...
My first boss complained that a page of my code was harder to read than a page of his code. I told him that one page of my code was a lot easier to read than the six pages of code he wrote to accomplish the same thing.