Slashdot Mirror
The Best Ways To Simplify Your Code? (dice.com)
Nerval's Lobster writes: Technical debt arises for many reasons—whether moving goal posts, pressure to get code tested and released, high programmer turnover, and lack of documentation. Over time, it can also render code a spaghetti-like mess. But how to deal with it? In a new column on Dice, developer David Bolton offers some suggestions, ranging from refactoring to using compiler inference to increase readability and shorten declarations. While those techniques are straightforward, it's clear that a lot of developers let their code get out of control, and trying to plan beforehand doesn't necessarily prevent the work from getting overcomplicated. It seems like every developer has a go-to technique (or four) for keeping things a little more streamlined. What are yours?
.
And then there is always this old chestnut... The Big Ball of Mud.
It seems like every developer has a go-to technique (or four) for keeping things a little more streamlined. What are yours?
The mess is just part of coding. Deal with the mess. Accept the mess. Live with the mess. Join with the mess. Speak with the mess. Hear its answers whispered into your head. Nod assent as the mess intones its instructions. Welcome the mess in and let its tendrils throw through your veins. Understand the mess's greater plans and become its corporeal servant on this earth. Hail the mess. Hail the mess. All hail the mess. HAIL!
He's the sort of person who would sell the Red Cross to Dracula.
No really, do not do this unless you actually need to make changes in the area involved. Diving into old code just to tidy it up brings its own set of risks, and they may simply outweigh any 'niceness' advantage.
Instead - black box it. Interface it off. Make your new code structured, shiny and gleaming. Do black box-style testing (inputs vs outputs, almost like futzing) against the old code's API and make sure your interfaced version produces the same. Unit test the hell out of your new code.
Over time, should you actually find a genuine need to, you can then start to look at the black box. Can it be made into a series of smaller black boxes? Can you interface those off too, independently? Cool - do it, one at a time, and use the same approach you used before. Eventually you'll either be left with nicely restructured code or, more likely, nice code that changes often and gnarly horrible stuff that doesn't change ever, but that's hidden behind an interface/library/<insert abstraction methodology here> and works.
Should always weigh the operational risk of changing ugly-but-known-quantity against shiny-but-unknown-quantity. The path of what to do will be different for every case.
Ok... it's DICE but I'll bite... What I have found: IF time allows, the technical debt can be revisited and cleared/reduced. Some schedules don't allow for this, but during non-peak times (like the week between Christmas and New Years) when stuff is slow, I like to revisit some of the bad places and do damage control.
.02
I think spotting these issues, and giving the developer enough time to re-visit the bad section of the code is ESSENTIAL to maintain a relatively clean code base.
Code reviews can help, but the project deadline pressure-cooker usually prevails. My
The best way is likely by not reading a Dice article.
When your question gets closed on Stack Overflow, then try to ask it on Slashdot?
Frankly, if your code is constantly getting out of control and becoming unreadable, you are not doing professional work, you are doing amateur work (and yes, I know that there are plenty of paid professionals who do amateur work. We've seen stories from Trend Micro programmers here recently on Slashdot).
It's not a set of rules to follow. If there were a mindless algorithm to follow, then a computer could do it. Instead, when you are about to write code, always ask yourself, "How can I write this in a way that future programmers can understand it?"
"First they came for the slanderers and i said nothing."
Think more. Write less.
Writing less code has many benefits:
Ideas that involve writing a ton more code to do X always backfire, the latest being TDD/IOC. That stuff is nearly impossible to read and maintain.
KISS (keep it simple, stupid)
Peter predicted that you would "deliberately forget" creation 2000 years ago...
has a go-to technique
How did they know my technique!?
Developer David Bolton has moved on from Dice and the remaining authors have been left scrambling trying to pull his notes and articles etc together to generate new content. They report having difficulty understanding how he cobbled together the disparate information into existing articles and have advocated just rewriting the articles from the ground up so they would be easier to maintain going forward.
When I take shortcuts because I am in a hurry, I try to leave breadcrumbs. I put comments that start with the string "FIXME" and then write a quick sentence or two explaining how I would do it if I had more time. Then later, when I do have time, I can just grep for "FIXME" and find a list of things that need to be fixed. Those comments save me a lot of time, because I have an explanation from when it was still fresh in my mind, preventing many "WTF moments".
These books provide much better information on the topic and deserve a place on your shelf alongside the GoF's Design Patterns.
I think what everybody is hating on is the undisclosed relationship. Nerval's Lobster is a shill account. This is not ethical business practice.
One of the checks I do is to have a non-programmer just READ my code. If they can make any sense of it (Think variable and function names) then I continue. If not, I rewrite until it reads like English (with extra stuff in the middle :-)
I also have SHORT (as in a single line or perhaps two) comment block at the start of anything that isn't immediately obvious. This adds to readability.
I have code blocks that are more than 10 years old, that I still refer to and which I can make out the intent and the execution without issue because of these two very simple techniques. '$a' doesn't tell me anything. '$account_name' does. Stop trying to limit your typing load.
Other thing I do, which I find missing from a a great many things; Check your inputs and your return values. As much as this is Programming 101 level stuff, it is remarkably absent from so much code. How is it that SQL injection works at all?
+4 insightful? Is everyone with moderation points 14 year old?
Apparently, and it ignores the simple fact that Dice probably sucks small and medium dicks as well.
So, in keeping with the thread topic, I'll simplify the original statement: Dice.com sucks dicks.
It must have been something you assimilated. . . .
I agree about code reviews: in fact I consider them essential in a team environment and wouldn't want to work in a code base where they will not be consistently held, at least going forward. Then the team can agree on some kind of standards and I recommend that the team develop a checklist for things the reviewer should check, where near the top of the list is: "Would I want to maintain this, and could I understand it easily if I came back to it years from now?". Also somewhere on the list is: "How was this tested?". Nothing ever gets into the master branch without such a review. Ideally the review is asynchronous, at least the first pass, to help see if the code is clear without its author explaining it.
Also, the coder should review his own code first with that in mind, before sending it to someone else to review.
Otherwise code becomes a mess. On a team small enough to enforce it, things can go much better.
A Free, fast personal organizer for touch typists: onemodel