1

I am currently maintaining/enhancing a project a bit old speaking of the 1990's. Atleast 15 developers would have worked over it. Going through the code for understanding is bit difficult.

  1. No coding standards being followed.
  2. OOP concepts not clear.
  3. Too many unnecessary methods and functions, also unused files.
  4. Worst of all global objects (hard to determine when its created and destroyed).

At times I feel should I be correcting the code so its better to work on, but my PM says we should not bother about it. As we have to finish the tasks within deadlines. This also leads to difficulties in tracking the bugs occurring.

Any suggestions on how should I approach it?

Shirish11
  • 1,469
  • 10
  • 22

1 Answers1

2

You should start commenting in the code where possible. Obviously this includes your stuff but make comments on other pieces, that don't seem clear or have some obvious coding flaw. At the very least this will make it a little bit easier for you to read when you come back to pieces of it and also for any future developers. At best, it will help you to make your case to your manager as to why you need to spend time fixing the code.

Managers will also never spend the time to maintain things, or so I'm told, they just care about getting it done. I would nonetheless start slowly refactoring it in the places you are working on. If your manager asks why, simply tell them it was so jumbled you had to do something to even be able to work on it. I'm not saying make it perfect, but clean it up as you go.

TruthOf42
  • 752
  • 1
  • 7
  • 15
  • I would caution just adding comments because comments are highly static and changes in code also means changes to comments which, inevitably, means more work. Utilize comments for clarity but not where obvious through simple code reading. – Mushy Apr 05 '13 at 13:22
  • I always try and put comments IN my methods explaining each part of the method. Even if they are obvious it's rare that I don't update these comments as I change my code. The same can't be said for comments that i put at the header of my method, though i usually just give a brief summary of what it does, nothing complex – TruthOf42 Apr 24 '13 at 14:08