Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Best Ways To Simplify Your Code? (dice.com)

Posted by timothy on from the throw-out-every-other-line dept.

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?

3 of 197 comments (clear)

  1. Re:Dice sucks dick. by iced_tea · · Score: 3, Interesting

    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.

    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 .02

  2. Re:be smart by Anonymous Coward · · Score: 2, Interesting

    #include main() { long long P = 1, E = 2, T = 5, A = 61, L = 251, N = 3659, R = 271173410, G = 1479296389, x[] = { G * R * E * E * T , P * L * A * N * E * T }; puts((char*)x); }

  3. Two things by DFDumont · · Score: 4, Interesting

    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?