Slashdot Mirror
Are You Proud of Your Code?
An anonymous reader writes "I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way? If so, then what is holding you back from realizing your full potential? More importantly, what if anything are you planning to do about it? I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe). I have worked for companies large and small in a variety of languages and platforms. Sadly the one constant in my career is that I am assigned to projects that drift, seemingly aimlessly, from inception to a point where the client runs out of funding. Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices? Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"
The answer to your question as to what is holding you back is complicated and multi-faceted. I'm sure you'll receive many interesting answers (and I look forward to reading them...hopefully it'll help me become a better coder).
From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.
But the number one thing holing me back is time. When I'm coding on the company's dollar, there's only so much time to spend in design, in writing test cases, in having someone peer review your code. And thus, there's just not enough time to spend doing things in the absolute, 100% correct way. There has to be some compromise.
I suspect that even if I had time, I would run out of mental energy first.
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
The product I work on at work features all three. It can be 'interesting' to maintain sometimes. That being said, it's frequently possible to rewrite sections and management sometimes listens to the programmer types and has let us restructure things sometimes. For example, we've mostly gotten rid of the RPC stuff.
When I want to satisfy my urge to work on good, clean code, I do some open-source work. Open-source tends to have that, because nothing else tends to work for very long.
PHEM - party like it's 1997-2003!
style is one eternal point of contention (except for python programmers, but they're in a straight jacket), I don't think that it is a part of 'are you proud of your code', that has little to do with what other people think of your code, but everything about what you think of your own code.
When I look at my own code it's a mixed bag. The stuff that I earned the most money with is actually programmed quite bad, some of the most elegant stuff I wrote is sitting unused on the shelf.
I find that in a commercial setting I'm far more inclined to 'cut & paste' to keep moving rather than refactoring just to save the time. Sure, it leads to maintenance headaches down the line and I quite often just scrap stuff and rewrite it rather than figuring out what it did and why. Tools evolve at such a tremendous clip that I don't think the lifespan of code is anywhere near the point where it could be justified to spend say an extra week or two to get an algorithm tweaked to perfection if the next release of the tool or framework is going to have it built in anyway.
Faster machines also lead to sloppy code, I'm running a lot of production stuff on uncompiled PHP, whereas in the past I've rolled out code in assembler because I could beat the C compiler by a couple of cycles on most tight loops.
Times are changing, and that is the biggest 'driver' against 'clean' code, it won't be long before the actual code will start to disappear. For some environments that is already happening.
Oh well, old guys like me will find employment writing for embedded systems, which are about a decade behind the curve.
MP3 Search Engine
Here are some pet peeves of mine involving dealing with other people's code. I don't think many of these are subjective either.
Generally, whenever I complete a set of code, it's perfect. It's flawless. It's the stunning pinnacle of coding, and it should go on some kind of display page where everyone can marvel at it, worship it and experience its perfection so they may find true enlightenment.
Usually, when I unearth the code 6 months later I wonder if there's any way to get this horrible piece of hacked crap out of the CVS somehow...
It's just that, well, you learn. You improve. Yes, even after more than a decade of coding, you still learn and improve. You learn new tricks, you learn to use new libraries, and you discover better and more efficient ways to use them by using them. So generally, yes, I'm proud of my code. For a while.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
In what other line of work does principal construction begin before the customer has defined what it is they are ordering?
A software is not a product in itself. It's not like an "apple" or an "orange", it's more like a "building" or a "vehicle". A building and a vehicle can be the solution to many different problems. A truck doesn't necessarily solve a customers problem if he's looking for a way to transport people in style from A to B.
But while I think that most people understand this, they have a very fuzzy and indistinct concept of the cost of changing the specification once construction has begun because you can't walk the customer out to the building, point at the construction and say: "To make the changes you require we will have to tear out that wall there, remove all the concrete laid here, that will require a week and scrap more than four tonnes of construction material".
This is where software engineering comes in: With a good model and by sticking to the principle that you begin with a specification from which you construct a series of test to see if the specification has been fulfilled. From the specification a design is made. The design specification is used to implement tests to see that the design has been followed. From the design the code is written and on the code the tests are run.
Now when the customer changes the specification you can look at the design and the code and see (hopefully) how substantial the changes will be and what the cost will be. Your customer will thank you for being more accurate in your estimation, for pointing out the costs (which is the only thing your customer will care about, remember that time is money and is just another type of cost).
I have so far only worked in one workplace where this model was used and it was used very successfully in my opinion. Writing all those documents surely sucked, until it came time for implementation, which was frighteningly quick and painless. The ultimate pride for the well documented, well planned, well concieved and tested code has made me utterly incapable of being satisfied with any other way of working (which is why I've switched jobs a lot).
Changing to a structured approach to working is costly, but the benifits are bountiful and will ultimately save money and time. I can almost promise that while you might lose a customer or some goodwill of a few customers in the interim, in the long run, the customers will flock to you since you are delivering on time, the functionality they asked for.
Badgers, we don't need no stinking badgers! - UHF
I still think in cycles, or ticks.
It comes from learning Z80/8080 assembler first, before BASIC, before C. Until that point, I knew a few macro languages.
In my mind, I'm still in a 32K machine, living with the OS, writing strings to hardware ports, and using my own interrupt vector code in concert with the host cycles to get work done.
When I work in C or C++ (heaven forbid #), there's a link list in my mind about array conservation, minimizing strings, using hashing and strict Booleans to get a job done.
No, I'm not an embedded systems coder; I just end up thinking like one.
My comments used to go thru an assembler, and I'd look at the code and try and re-optimize it. And when my code would explode, it would explode to unrecognizable shards of crap until I learned atomization (objects) and resource re-entrance. Now when my code doesn't work, my deadman's switch monitor twigs, which backstreams messages. It makes coding highly involved, but vastly more productive because *I CAN* reuse my code.
I worry more about the OS than my own code; there's so much that's not predictable in operating systems today. They should do more work with smaller kernels and leave modularity out of the kernel. Just my 2c.
---- Teach Peace. It's Cheaper Than War.
Yes. Every project I have worked on has had design standards, coding standards, and peer reviews. Yes there were tight crunches on time at many moments, and the quality of code does suffer at those points, but overall the code lives up to the standards and is better for it. It is easier to maintain, debug, update, refactor etc. because it is well designed and implemented. I very well could be an anomaly but I have to believe that in order to ensure that a system requirements were meant (in the form of Ilities) you need to have broad control over the code (how design decisions are developed, and enforced).
je suis parce que j'aime
Once in a while I take a small change and tell the client/boss/myself that it is a really BIG change.
Then I go through a totally re-write the code from end-to-end. I look for unused sections, variables, etc. I re-order all the logic so that it is logical. Then I test for the necessary period of time.
Since most of the code is already written, I start by writing out the business rules and I make the order of the code follow the order of the business rules, more-or-less. I put ALL of the business rules into the code as comments. I also send the rules to the client/boss/myself/others.
Doing this just once a year, on each critical section of code actually saves me much more time than the initial investment, so everyone wins.
- I live the greatest adventure anyone could possibly desire. - Tosk the Hunted
On the agile, small-functions stuff, there is a reason that agile programming is mostly meant for languages like Java; most agile teams have testing harnesses which will tell them when a small function is no longer used, or how many places a small function is used. This does not solve the 'forest for the trees' problem, but does at least eliminate the fear of deleting small orphaned functions.
I do otherwise agree with all your points; the best place is a middle ground between agile's self-documenting and the traditional ZOMG COMMENTS. At my (non-agile) workplace, we document at the top of each function what the function does and what it takes and returns, as well as documenting any complex or unintuitive block of code within a function. (The ideal would be to avoid unintuitive code entirely, of course, but this is not always possible when dealing with things like VoIP goo.)
--Rachel
My last two projects have been to babysit and sun down legacy systems. These were written in Perl, are web & database based, were written over a period of about ten years by multiple people, had no development system (all changes are made in production), and are each at least a half million lines of code.
One such system has two very different kinds of programmers. One kind produces very small, tight, elegant code. Each line may be complex, but there aren't very many of them. Another kind generally codes for conceptually easier tasks, and has a verbose style. Individual lines are trivial assignments, but there are sometimes thousands of them.
The elegant code is MUCH more difficult to debug. It's also, generally, broken much less often. The verbose code is generally very easy to fix.
But i've gotten an appreciation for other ways to do things. And, there aren't nearly as many of us 'elegant coders' out there for replacement. But i still don't see how some apps can be accomplished at all without us. This appears to be language, library and tool independent. Fred Brooks seems to have something to say about this.
I'm firmly in the realm of 'elegant coder' myself. My favorite piece of late is 750 lines of very dense code involving a seven dimensional hash (but sometimes six - it varies) with dynamic indexes. It replaces a 25,000 line chunk that had to be changed every year. The new bit never needs change. However, despite ample documentation and three tutorials, i was unsuccessful in showing the new team how it worked. The new system has designed this bit out completely.
One thing about both projects is that the employer either started a project to replace them, or actually replaced them. In both cases, it was an incredible amount of work and expense to do this. Millions of dollars. It would have been both cheaper and better to fix their problems, and update their user interfaces. At least, once an appropriate programmer was found. Oddly, we have at least two on our current team.
Oh, yes. The replacement projects went over budget and were late by at least a factor of two. Much more, if you consider that something like half of the functionality was removed. And there seems to be one chunk that the new team doesn't seem to be able to deliver. Perhaps the new team needs an elegant coder.
-- Stephen.
I fully agree. I inherited a LOT of uncommented and shittily commented code, and it is a royal PITA to figure out WHY it is doing what it is doing (which was basically your point). On the other hand, at least with crappy comments, there is occasionally a nugget of useful information...I despise the comment-free code more, but the code itself also looks like it was designed by someone on an acid trip.
.NET. And the other programmers whose code does NOT suck (separate project group) have given me positive feedback on what they've seen of mine. A limited degree of self-doubt is good for keeping you honest with the quality of your work, but don't worry about it TOO much.
So yes, comments should say WHY more than WHAT (specifically) a line or block of code does. A short narrative is usually the most helpful, ime. Basic description of what the method (or even a crucial line if it's the least bit unconventional or otherwise unintuitive) does (in bird's-eye-view terms / how you would explain it to a non-programmer), and WHY it is doing it if that purpose isn't obvious from WHAT.
And I also say (most of) my predecessors' code sucks, but in this case, it does. There was one guy who seemed to have a decent idea of what he was doing, and I think he got burnt out by the complete buffoon of an "IT Manager" they had at the time (hurray cronyism! He still works here in his own project group because he's friends with the big boss). But the other guys...one would have actual end-user visible error messages like "the stupid polack messed up again", and had one of Shakespeare's plays in its entirety linked on one of the maintenance web sites. The other guy consistently set up SQL accounts with "password" and sysadmin privileges (I've gotten it secured now, but it's causing quite a bit of havoc for some users). Crazy and stupid, respectively. Then we have a contractor (still with us, hopefully not much longer)...who is arrogant AND stupid (with coding, anyways...quite manipulative with the non-technical people who control his paycheck). He implements concepts and technologies that he does not understand in completely useless and excessively complicated ways. He also has a big problem with turnover of his underlings, resulting in even crappier code. The rest of us want to completely scrap his project because it's so bad (the aforementioned "acid trip code"). But you know what they say: "CONTRACTING: if you aren't part of the solution, there's good money to be made in prolonging the problem."
I am lazy: I make sure it works before it goes out, and I write it so the user can configure it to do what they need without having to bother me to do hard code changes, recompile, and redeploy. I've already got enough of that with existing code I've not yet had time to rewrite.
So, in short, if you are neither crazy nor stupid, your code probably won't suck that bad. Every time I'm skeptical of my own code, I just look at the code I am maintaining and replacing. I simply remind myself: mine actually works. I wrote them from start to finish, so the code is consistent. My boss can look at it and understand what it's doing with his experience with older languages and teething knowledge of
duplicate what the code says in another language (i.e. english).
Some of the time, that is correct. Most of the time, it isn't. But that's just in my field (financial software). There are two languages in use in the software I write and maintain: "code", and "business". It is vital, in my area, that code is commented well, to explain the business reasons behind the code. Small loops sometimes speak for themselves and don't need commenting. For example, a method called "getAllCashSecuritiesForAccount", if it contains only a simple loop, doesn't need commenting.
But because developers come in who don't have a financial background, and don't know their way around the system, comments in the code are essential. It helps them understand both the code they are looking at, and the business flow.
But the main reason for having clear, concise comments in the code is so that you don't have to read the code. For example (apologies for the VB):
The above comments are all aligned. They appear in the IDE in a different colour. They are written in plain English. They are clear and concise. If I am looking for a bug which involves the total value which has changed being wrong, then from scanning 3 lines, written in plain English, it is fairly clear where I should start my search. Yes, given a few more seconds, I can read through the whole code, and see what is being done. But it's quicker and easier to read 3 lines of English than 15-odd lines of code, which aren't aligned.
In fact, possibly the most useful aspect of comments like the above are to eliminate all the code you don't need to read.
You could argue, of course, that the above could be broken down into 3 seperate methods, all clearly named. But I think that's overkill. This is a simple method, doing three simple things. I ought to be able to read it all the way through without having to flip between three different methods, which exist only to save the developer taking the time to type some clear comments.
Lastly: yes, I am aware that the above code performs two seperate iterations of the same objects, and is terribly inefficient; it is for illustrative purposes only, and on no account should be treated with any seriousness
'No rational religion claims "supernatural" exists, that's an atheist slander.' - seen on slashdot.
The biggest thing I see wrong with other people's code is not at the syntax level or to do with commenting. It's based on a misunderstanding of basic CS principles. An example is in order from last week...
In the codebase I work on, there's a module that analyzes documents and tags them, assigning different weights to each tag based on relevance. (Think of the way google works--it reads a web page and tags it with terms, then if you type in one of those terms while doing a search that document comes up--yes I know this isn't the way google actually works, save it. :-p ) At one point we send a list of tagged documents from one system to another, and this area was the source of many, many bugs. The responsible developer spent the better part of last week slaving on this code and every change seemed to introduce more bugs than it removed. Finally, I got involved to see what the problem was.
Here is one thing (out of many) that I found. After the docs arrive in the new system, each doc is supposed to be persisted along with the top 5 most relevant tags (the rest discarded). The code was written to create a Document, check a hash table that maps the doc to the number of tags it currently has, add a tag if that doc doesn't yet have five, then increment the value associated with that doc in the hash table. When I saw this, my head almost exploded. At some point, this developer thought it would be a good idea to create a hash table and keep this information, information which is available in the document itself (he could've just called doc.getTags().size() to see how many tags it currently had). Now he created this hash table and all his code was written to depend on it, so of course he had to write a lot of code to keep it in sync with the state of all these documents.
This sounds like a simple enough thing, right? It's not necessary, and it's not the best thing, but it's a fairly simple mistake and one that couldn't impact code readability all that much, right? Maybe--but consider that this is one of about 10 simple mistakes I found, and you can imagine the explosion of interactions of all these simple mistakes...and that's why we burned a person-week on something that should've been trivial. When I pointed out to this developer that he could just get the number of tags directly from the doc itself, and doesn't need to keep this state in some other object too, he said something to the effect of, "That's a different approach, but whatever...one's not better than the other."
But one is better. If this developer understood the difference between intrinsic and extrinsic, he never would've written that code in the first place much less defended it. To put a fine point on it: the number of tags associated with a document is intrinsic to the document itself, so that is where the information should live...not there as well as some hash table somewhere. The document is the authority and the final word on how many tags it has at any moment in time. (There's a principle in databases called the SUA Principle--it means one should keep data in a Single place, in an Unambiguous manner, and that should be the Authoritative source of that data and no other. It applies here too.) Putting this info into some other object, even if that object exists solely for the purpose of tracking that info, means you're creating an object that stores information that is extrinsic to it. Never a good idea...now you need a whole bunch of supporting code that keeps the extrinsic info in sync at all times.
Let's say I'm designing a Ball class for use in a physics application that students learning physics can use. They can shoot the ball out of a cannon, put it under water, in deep space, on Jupiter, etc, and see how the simulation behaves. As the developer of this class, I decide to add a characteristic to the ball that keeps info about its "heaviness". What should I add, a getWeight() method or a getMass() method? The developer I was talking t
but have you considered the following argument: shut up.