What is the thing that irritates you while doing maintenance coding?

Question

What is the thing that irritates you while doing maintenance coding?

Can you point out some points for easier maintenance for me and my fellow programmers?

Answer 1

That I cannot resist refactoring it. Even though it's my own.

And that after refactoring, the original idea seems clearer, and not so bad at all...

Answer 2

That it's my own code that I have to maintainence on, so I can't blame someone else when it's not working...

Answer 3

A WTF-per-line ratio greater than 1. :-)

Answer 4

The fact that such code is usually riddled with many bugfixes. Uncommented bugfixes, so you have no idea why the hell the previous programmer returns from function x when y equals '5'.

Answer 5

When the only design documents are the codes themselves, written by someone I don't know or can't get access to. And the codes have no comment.

Making it worse will be a lot of redundant (if I know at all) files/codes/DB tables/columns which confuse me further, not to mention time wasting.

Answer 6

single letter variable names! (This does exist, today) Ackkk

Answer 7

That the unit tests don't exist, and the code hasn't been architected to facilitate unit testing. So I'm faced with code that doesn't have defined behaviour (via unit tests). I then have to change the code to be testable, and that in itself could change the behaviour and remain undetected....

Answer 8

When the code doesn't make best use of the language. Use the language the way it was intended.

Concentrate your maintenance on clarity and correctness: Use smart pointers here, make this a class. Catch that exception and clean up before rethrowing. Don't go crazy making huge architectural changes unless the existing architecture is causing the problem, or preventing you from fixing actual bugs.

Answer 9

That my child, who was so beautiful when she was born, has turned into an ugly brat who won't stop talking back nor do what she's told. Not content with that, she makes a point of embarrassing me in front of all my friends.

As for a suggestion: unit tests -- at least that way you can remember (or figure out) what she was taught as a child and make sure you don't break it (unless that's the point).

Answer 10

That everyone else is a complete moron, totally screwed up the design, created an unmaintainable mess of spaghetti code, commented the easiest stuff and forgot to comment on the hard-to-understand stuff.

The most irritating thing is that, much too often, it's a former me that was the moron.

I guess I just don't like digging through stale code.

Answer 11

When the code I am maintaining is written badly, without oops, using wrong or messy architecture, because then I have to either change a lot of things or act as wrongly as the previous coder did.

Answer 12

Can you point out some points for easier maintenance for me and my fellow programmers?

One word: Refactoring.

Answer 13

Worse than uncommented bug fixes is comments that are out of date or just plain wrong.

Answer 14

When I realize the code I am debugging is not even working. It was simply not tested enough. And I am wondering how come this code was checked-in. How come someone else could have think it was working.

Answer 15

#ifdef BAD_CODE
... stuff that has been useless since ages
#endif

a couple of useful lines

#ifdef BAD_CODE2
... more stuff that has been useless since ages
#endif

And so on, ad nauseam. This construct can be handy to test your hypothesis, but these bad blocks have to be removed asap.

Answer 16

When you have large sections of commented-out code without any explanation of why those sections have been commented-out. Usually this is just a lazy alternative to version control, but sometimes it may indicate a temporary fix that the developer is unsure of, or some other condition you are not aware of.

So do you leave it? Delete it? Make a back-up and delete it?

Answer 17

• Unclear variable names e.g. m_strObjArr
• .NET code littered with Hungarian Notation, especially when applied inconsistently e.g. m_strI, strI, objArr (Microsoft recommends not using Hungarian for .NET naming: http://msdn.microsoft.com/en-us/library/ms229045.aspx)
• If-then blocks without braces
• Duplicated code. This is especially irritating when the same JavaScript or C# method is pasted on every page in a site instead of it having been factored into a common file.
• No instructions on how to get the code running on a local development machine or deploy it to production.

Answer 18

The thing that irritates me the most while doing maintenance coding? Easy.

That management thinks that any fix can be done as easily as flipping a light switch. That any fix occurs in a vacuum, that it won't have any side-effects, that it all works like magic.

And that no amount of logical, rational explanation will convince them otherwise.

Answer 19

Coming across bugs caused by someone copy-pasting a chunk of code and then not actually modifying it to get the correct behaviour in the new place (let along the fact that they copy-pasted in the first place).

That's my current one anyway, having come across it most recently while doing maintenance coding :)

Answer 20

Comments written in a language other than English.

Answer 21

• See copy-pasted code from experts-exchange.
• See your own code broken by another guy.
• Find awfully written unit-tests.
• Don't find them

Answer 22

Code duplication.

I've seen code where entire methods (even classes), had been copied, and then parts changed. Sometimes you had classes of >1000 lines, with 80% of the code identical. Just hunting down all the places to change something can be a nightmare.

The first thing I do is usually try to refactor this (which is not always easy).

And yes, I sometimes find it was my own code (though I hope I'll never do it like this again).

Answer 23

Uncommented code, compact statements (e.g. single line ifs etc) and inconsistent variable naming.

Oh and I'm a real stickler for nicely laid out classes, keeping properties, methods, constructors and private variables grouped together.

Answer 24

1. Discovering that the existing code is written in PERL
2. On examining the PERL code, discovering algorithms like the following:

Suck whole file into memory, substitute all newlines with some char, record the substitution count, open the same file again, start a for loop from 1 to the count of substitutions, read a line, do something.

I kid you not!

Answer 25

What is the thing that irritates you while doing maintenance coding?

I am more often than not annoyed that I am working on code which I had been done with for some number of months, if not years. It's not so much the coding that bothers me, it's just that I mentally check out on certain projects after a given amount of time as I move on to future projects. Older projects become less interesting, yesterdays news so to speak.

Also, as time passes, I tend to forget the workflow of the code I was previously working on. Concise comments are a real time saver for cases like these.

This is particular to web development in my case, but I know it carries over to all branches of development.

Answer 26

hard-to-read code:

• wrong indentation
• inconsistent coding rules or no coding rules at all
• useless comments (I prefer no comment)
• out-of-date paper documentation

Answer 27

Unexpected non-local scope of the code, i.e. you change something in one part and in some almost incomprehensible ways, something else in a completely different part of the system suddenly fails. Drives me mad.

Answer 28

You are fixing the most critical bugs in the most critical system, and your peeky research collegue says: "Oh you are still maintaing code. That's so kid stuff"

Answer 29

Giving a workload estimate for discovering and fixing a tough bug when initial information is the issue report stating "The software doesn't work". Usually my answer is: "between two hours and fifteen days"

Then justifying why I spent two weeks for adding only a couple of characters here and swapping two lines there.

Answer 30

Very easy. Swallowed exceptions. e.g. (c#):

try
{
   //Do something
}
catch
{

}

//Keep doing something else.

This leads to all kinds of fun bug hunting, usually based on a bug report that you can't recreate. My motto to all juniors is now to never (ever) swallow an exception without logging it.

(Close second is badly written code within a transaction, where an error causes the transaction to hang, and the only error message you get is about a locked DB, with no explanation of what caused the original error).

Answer 31

Lack of unit tests to go with the code. I can live with no-comments, useless-comments, less documentation etc. But no unit tests, that a hell.

Answer 32

Dealing with code written by six different people who all thought they had the right way of doing things and should do nothing to respect the patterns of those before them, even at the most basic level.

Ever tried to read code that is camel case or pascal case or hungarian, and that changes within any given class or function, with three different comment styles? Sprinkle that with a few derisive, note-to-self comments ala "this xyz prior person was wrong but I don't have time to fix this..."

Answer 33

Public interfaces with methods like:

DoFoo1()
DoFoo2()
DoFoo3()

Remember people, if you make it public and release it - you have to support it forever!

Another one is to find a nice long comment that someone has clearly taken the time to write - but the code it was originally next to has either changed behaviour, moved or been deleted.

Answer 34

Nothing. I love coding. I love maintenance coding. The sooner you all come to peace with, and find passion for your jobs, then you'll see that things like petty irritations are a fabrication of your own minds, and have pretty much nothing to do with the code in front of you, or how "unbelievably bad" it is, etc.

Answer 35

• duplicated code
• bad identation
• unclear variable names
• magic numbers
• magic string constants
• very long methods
• unclear naming of methods
• out of date documentation
• inconsistent coding rules
• lack of revision and authors tags
• lack of documentation
• no OOP at all
• copy & paste
• anemic classes

Answer 36

My biggest pet peeve: code rot.

In other words: we start out with a pristine, beautiful application. Over time, new features are added to it -- of course, whoever is working on the changes just slaps their code anywhere. Another person works on the code, can't figure out what its doing, and just wedges their new fix or feature wherever it fits. Fast-forward a year or so later, your once shiny and polished code has turned to rust. Its barely held together with duct tape and rubber bands.

So, what happens next? Management wants a shiny new feature added, but you can't work it in without architecture or database schemas having an impact on existing code. You've got deadlines to hit, so what do you do? Write a hack that sort of works, wedge it in wherever it fits, and hope you have time to fix it later... [cue the Lion King's "Circle of Life"]

Answer 37

People who think you can get that critcial show-stopper bug fixed faster if the call you every five minutes.

Answer 38

Currently, multiple rounds of undocumented shortcuts and cut and pasting code resulting in incorrect comments, method names, and variable names, so that it requires a code anthropologist to pick through and figure out what it is doing, what it should be doing, and what the original dev might have intended it to do.

Answer 39

When not one developer in the company wants to own up to the current functionality of the code...

Answer 40

The book Clean Code by Robert C. Martin contains a lot of example of how to make code easier to maintain.

Answer 41

One thing that can wear on you very quickly is inconsistent formatting. Even though most modern IDEs will do fairly well in keeping it in a neat format (well maybe not IDLE :) ) people will still find a way to make their nests look like sylvester the cat just got done with them.

That can also be a piece of advice to help make maintenance easier, develop and enforce a department code formatting spec....depending on what you are working in, there are some built in "code style" formatters (IntelliJ IDEA) and tons of third party ones(Visual Studio).

That way when the coder is banging out code, it could look like all hell, but after unit tests and they go to commit to the source repository, they just pass it through your groups' formatter, and its nice and tidy when it's committed.

Answer 42

Uncommented code.

Yeah, we get it, you think you're God's gift to programming and that your coding is "self explanatory". I don't care. Comment your damn code regardless. You have NO IDEA what type of programmer is going be coming in after you; it could be someone fresh out of school that isn't aware of the techniques you use.

Answer 43

Developers who take offense to the fact that you changed "their code" and that there is nothing wrong with it. The problem is always "somewhere else" in "someone else's" code. So I guess it would be developers who presume he or she is infallible.