Slashdot Mirror
Any "Pretty" Code Out There?
andhow writes "Practically any time I hear a large software system discussed I hear "X is a #%@!in mess," or "Y is unmanageable and really should be rewritten." Some of this I know is just fresh programmers seeing their first big hunk o' code and having the natural reaction. In other cases I've heard it from main developers, so I'll take their word for it. Over time, it paints a bleak picture, and I'd be really like to know of a counterexample. Getting to know a piece of software well enough to ascertain its quality takes a long time, so I submit to the experience of the readership: what projects have you worked on which you felt had admirable code, both high-level architecture and in-the-trenches implementation? In particular I am interested in large user applications using modern C++ libraries and techniques like exception handling and RAII."
The cruftiness of source code is directly proportional to the amount of time spent working on it times the number of people working on it.
Has someone created such a law before?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Is an artist ever happy with a painting?
Trends and tastes change. If any coder is 100% happy with a project, they're in the wrong field.
Well, you'll always find people that say a code base is a mess when the better word would be different. I have a if statement with out { and } to close it... Is it needed in C++ for a single line? Nope - does it make it clearer and easier to read? Yes to me - and my friend Chris will tell you exactly the opposite...
And on a related note - why rewrite? Can't people ever just go for cleaning something up? No cause then you are just doing mindless reformatting - while if you rewrite, you can claim you make it better, faster, whatever... So of course people will say its better to rewrite...
Finally, all mature code is a mess. If I rewrite it, I concentrate on the core piece of functionality... That is going to be small, lean, pretty and fast... Then the code matures - it gains more features. It gains portability. It is being worked on by many... and suddenly your re-write is no better than the code you set out to replace.
Peter.
1) Cleaning up code is a job to do after the code is done.
2) The code is never done. Refer to rule one.
I find the thing that really makes code unreadible is inconsistency. This is particularly true of languages like C++ where there is no well defined one true coding convention. If all your code is in house, this is not such a problem, because you can define your own coding convention and stick to it. If however you are relying on other libraries, chances are your going to end up with one library that names its function like_this, and one likeThis, and another fnct_LikeThis ...
Worse is when you don't even define a coding convention for the code you throw into the mix. Now you have libraries with inconsistent naming, and multiple developers all using their own favorite notation.
Additionally, their is inconsistency in the functioning of libraries. Some use function pointers, some work by inheritance, some (like glade) read the export list..
I'm not a huge Java fan, but I think they have maintainability down pat. Very consistent language, well defined coding convention, and a mature set of defacto tools (JUnit, javadoc, log4j, struts, spring, hibernate, etc..) make it a lot easier to jump into older code because everything feels familiar. In most other languages you have to spend quite a bit of time just decrypting the existing code, and then more time learning the particular API's they've chosen.
Just about all code I have seen written in python is great looking stuff..mainly because of
the imposed indentation and clear language characteristics.
Got Code?
postfix (the mail program) looks pretty nice to me.
Boost is what I call "template madness". It uses template metaprogramming to the max, which (in the real world) means three things:
(1) It's impossible to debug. You can't read the code. The debugger can't unravel the templated variables and stuff in any meaningful way for you. You can't even step through code, that's doing a supposedly simple operation like memory allocation!
(2) Some compilers will choke on the code, or compile it wrong in subtle ways due to differing interpretations of some obscure section of the enormous C++ language spec.
(3) The error messages from the compiler are useless. You have to run them through a filter to even figure out what they mean.
(3) Bugs in the library are very difficult to fix. Template metaprograms are essentially programs written in a functional language, except one that has horrible syntax. This is not the stuff that normal C++ programs are made of.
Your mileage may vary. My day job is working on a game engine for an upcoming Xbox360 game. Engines are hard enough without impractical crap like template metaprogramming in them. Give me straight-line C/C++ code any day.
"Any app that doesn't need to be rewritten hasn't grown sufficiently beyond its original intent." - Jesse Litton, 1990
"I've seen plently of good programmers declare code 'ugly' because it had a few warts but in reality they just couldn't understand it."
If you can't understand the code it's the author's fault. That is if you have mastered the syntax of the language of course.
I'm currently working with an embedded code base that was written for job security. Everything is somewhat elegantly organized, but nothing is commented and functions are usually 200 - 500 ELOC. There aren't any notes explaining module interactions with module descriptions or example usages. Considering the project size is around 25,000 lines that makes the code very dense. Sure in 6 months I can document it and have it usable for a team again, but if I don't have time for fixing bugs or adding a feature, contractors will need to be able to come in and work on it with a minimum of rampup time. 6 months is not acceptable.
Not everyone needs to understand the derivation of every algorithm used, but they shouldn't have to perform the work a second time to verify its accuracy. Unsustainable code is ugly. If the average programmer can not read the source with documentation and understand its purpose, then the original programmer is at fault for not expressing themselves in a way that others can understand. This is why senior programmers make coding standards and do design work.
Phoenix Technologies used to make both BIOS and printer software. The printer software department split off and became a different company, and then I lost track of them...
They made printer software that went into virtually every printer not made by HP at the time. Canon, Ricoh, Lexmark, or whoever would come out with new hardware and license the software from Phoenix. Yep, some of my code is in every Lexmark printer right now.
They had a couple hundred thousand lines of code that did PCL, GL, and Postscript for the consumer market, and it was the most readable and well developed code I have seen. Comments were explanatory, variables were well named, and execution paths were well defined and easy to follow.
They really had their act together for testing as well, with an elaborate and comprehensive regression suite that checked *every* aspect of all of the [printer] languages, and a team of QA people who would go over the results nightly. I'm not making this up - you would come in to work in the morning and there would be maybe 5 E-mails from QA outlining bugs which were either in your code or assigned to you for reasonable reasons.
We did the software for the first Lexmark printer. The first internal release gathered 900 bug reports from QA. When we went to market there were 7 remaining, all of which were deemed inconsequential.
When you are in the commercial market making fixed-program computers (dishwashers, printers, cell phones, VCRs) you don't have security updates and new versions, and a recall is usually out of the question. It's much cheaper to do all of your QA up front and ship a quality product.
In my opinion we've grown sloppy in the programming business. I've been a contractor for the past 30 years and I haven't seen anyone else who comes close to true quality procedures. Even FAA safety certified stuff is usually hokey and obscure. Thank god we've still got human pilots.
Having seen the procedures firsthand I have an appreciation of how easy and valuable it all is. No one else seems to understand that, and so everyone keeps running around putting out fires and slipping deadlines.
If that's truly how your code works, you need to fire your boss!
Every project should budget resources to future-proof the actual code by cleaning it up and writing adequate documentation, and I don't mean a cookie-cutter paragraph for every single function. I mean do what needs to be done to ensure that the next time you have to work on that code, you won't waste twice as much time re-learning what it does.
Managers who ship code the minute it compiles are either assuming the project will never be revisited, or (most likely) they are complete imbeciles.
-Billco, Fnarg.com
My take on C++ is that the best programs only use a fraction of the features. The language is so big it is dangerous. Just because a feature exists in the language, does not mean it is good for every application. I am very wary of operator overloading and templates too. You need to make your code sufficiently clear that you can be sure it works. if you cannot quickly understand your code, then chances are you made a mistake.
"And don't forget that postfix is well-commented,"
In all fairness, nobody has ever cashed in on Bernstein's security guarentee. There have been some oopsies with postfix.
I think Bernstein's code is as nice as it gets. Course, Dan is polite to me too; so maybe I live in an alternative universe.
Need Mercedes parts ?
I came in here to say exactly that. The design and source to Tcl and the source to AOLServer are actually clean, clear, and elegant. I think much of that is thanks to the Tcl/Tk Engineering Guide.
By the way, your response is ridiculous in many ways. I don't feel like I should have to point these obvious things out to you but I guess I do:
1. The GP sounds like he understands template metaprogramming very well. Nothing about his post suggests that he either a) says that he is an "expert" (as you are suggesting he does), or b) *isn't* enough of an expert to have formed a valid opinion on the subject.
2. Clearly the GP used the word "impossible" to mean "very difficult". You're being pedantic by suggesting that he literally meant it is impossible to debug.
3. It's only because of lots and lots of dedicated effort by Boost developers that Boost's very-complex template metaprogramming techniques work on a wide variety of popular compilers. I would be willing to bet quite a bit that they had to jump through many hoops to find least-common-denominator solutions that worked on all compilers. I believe that this makes the GP's point perfectly. This kind of programming relies too much on subtle complexities of the language definition and while the Boost authors were willing to put lots of work into making these things work on various C++ compilers, I wouldn't want to do that and wouldn't choose to use a library that may force me to do the same (which might happen if I decide to extend Boost's implementation).
4. Once again by "useless" the GP clearly meant "requiring much more work to decipher than other more conventional error messages". Once again you dismiss his point by interpreting it completely literally.
My rule of thumb as a developer: whatever you do, make sure that the next guy who wants to work with it doesn't have to get a Ph.D. in the subject in order to continue your work. In other words, keep your implementation simple and as mainstream as possible, so that it can easily be picked up by anyone. Template metaprogramming fails this utterly.
I've been coding for 35 years. The only code that I've written was written by (surprise, surprise) me. The code that I've read has been written by hundreds, if not thousands, of people, who out-number me considerably. But wait, you say, you were talking about reading about writing code. However, much of the code that I read is at on-line sites like Perlmonks and O'Reily and even MSDN, where each bit of code is accompanied by detailed explanations of why it was written the way that it was. If that's not reading about writing code, then I don't know what is.
Nothing for 6-digit uids?
As the inventor of "literate programming"[1], early practitioner of open source, and author not just of The Art of Computer Programming and its included programs, but some extraordinarily elegant and widely used software systems himself (including TeX and METAFONT). How many people's programs are worth printing as hardcover books?
[1] mention also to Kernighan & Plauger's Software Tools.
you had me at #!
...almost always want to re-write old code from scratch.
Almost always without taking the time to understand what that old code does. Why? Because writing code is much easier than reading code. Reading code takes perseverance and ability to focus on large numbers of nit-picky details. Something our TV-age brains cannot easily do.
The result of throwing out the old code without understanding what it is accomplishing is not always positive from a business perspective.
Sure, sometimes crufty code is crap.
But sometimes, like on a terminal emulator project I worked on in the mid-90's, the cruft was a bunch of code, accumulated from 1985 to 1995, that actually emulated the bugs in the firmware of 10 different manufacturer's dumb terminals. The programmers who wrote the applications that ran on these dumb terminals relied upon these bugs in the firmware and when the bugs disappeared, the applications broke.
The company that tried to sell the "correct", "new", "elegant" terminal emulator hit a big solid brick wall called "market acceptance." The company that kept the cruft made roughly $4 million per year in profits and supported 25 employees' and their families for a decade while they developed new products.
So, before you look at code in a shipping product and say to yourself "this is crufty crap and should be re-written from scratch" ask yourself this question: "Do I really understand what this crufty crap is doing?"
I remember when that cute little home computer came out, and all the programs were just so. . , plinky.
Memory was a huge barrier, because you only had a small quantity of the stuff, and nobody understood the architecture of the system well enough to produce efficient programs.
But back then, there were no video card upgrades. No faster processors and mother boards being produces every three months. If you wanted higher speed and cooler graphics, you had to write your code in more ingenious ways.
And so that's what happened.
By the twilight years of the Color Computer, the games people were writing on that thing were unreal. I remember looking at a few and thinking to myself, "This is the same computer? Wow! Humans rock!"
When you reach the raw power limitations of your muscles but you still want to improve yourself in your combat skills, you take up Kung Fu. That's how it was in the old home computer days. Nowadays, though, (dang kids; I hadda walk fifty miles to school!) it seems that the bulk of improvement comes with the purchasing of increasingly large muscles.
This is not to say that there is no software innovation. Heck, id Software did some pretty amazing things with software ingenuity. But I do remember thinking during the first few years of the big PC revolution, after the 486 was reaching its twilight, "You know, all this hardware innovation is great and all. . , (big muscles are cool), but part of me wishes it would stop cold for six solid years just what would happen when the programmers were really pushed. --You know, to see what one of these machines is actually capable of doing.
-FL
As you note, the answer is mostly no. In my experience, it is the experienced people who are more likely to complain about code quality, as they can better recognize it and value it more. I just wrote an article about the need to make code more 'pretty': Why You Should Polish Your Code. One code base that has consistently impressed me is the Spring Application Framework, which is open source and written in Java (I'm primarily a Java developer). I've looked at other popular open source Java libraries and generally have not been impressed by their code quality, so I don't think that open source is any guarantee of prettier code.
So many programmers in the world need to have their keyboards substituted for a pair of reading glasses so they can learn some basic competence.