Get warned about old code

[Jonathan Lee]

Hi all,
does anyone have a good method for determining if some code is "expired"? Ideally, I could put something in the code like

#if __DATE__ > "01/01/2015"
#warning "Your code is old and is due for maintenance/rewrite"
#endif

But that obviously doesn't work. The idea is that in a couple years I should at least /look/ at the code to see if it should be cleaned up, refactored, etc.

How do people usually handle this?

Thanks for any advice
--Jonathan

 

[Victor Bazarov]

does anyone have a good method for determining if some code is
"expired"? Ideally, I could put something in the code like

#if __DATE__ > "01/01/2015"
#warning "Your code is old and is due for maintenance/rewrite"
#endif

But that obviously doesn't work. The idea is that in a couple years I
should at least /look/ at the code to see if it should be cleaned up,
refactored, etc.

How do people usually handle this?

Your development process should probably contain some kind of recurring
project to "/look/ at the code to see", but it keeping reminders about
completing that recurring project in the code itself is probably not a
good idea.

If you comment your code, you might decide on some kind of header for
each file, and the header might have the date of last modification or
review, and then your process could be supplemented with a utility to
scan through your code and report which modules need to be tended to, or
whatever. I've not seen that done, but it might be what you meant. In
general, however, good code does not need to be looked at *unless* it
somehow sours up (which is usually found out through testing), IOW tie
it to the functionality of the code, not the date of its writing or
style or whatever else you can think of.

Good luck!

V

 

[Jonathan Lee]

Your development process should probably contain some kind of recurring
project to "/look/ at the code to see", but it keeping reminders about
completing that recurring project in the code itself is probably not a
good idea.

If you comment your code, you might decide on some kind of header for
each file, and the header might have the date of last modification or
review, and then your process could be supplemented with a utility to
scan through your code and report which modules need to be tended to, or
whatever. I've not seen that done, but it might be what you meant. In
general, however, good code does not need to be looked at *unless* it
somehow sours up (which is usually found out through testing), IOW tie
it to the functionality of the code, not the date of its writing or
style or whatever else you can think of.

Thanks for the suggestion about time stamping the headers. That might
be workable, though it relies on someone running the check. I'd much
rather have something checked during compile, so it can't be avoided
or forgotten. I suppose it's easy enough to work that into a Makefile
or something.

As for what to tie it to, I'm using unit tests to be sure of the
functionality. So I agree with you on that. Still, I'd like someone
in a few years to at least /think/ about dead code, outdated practices,
todo items, documentation standards, external dependencies, etc.

 

[Jonathan Lee]

#if MY_PRODUCTVERSION_MAJOR==3
info +=
"Copyright © 2007-2012 ABC DEF, Inc.\n"
"Support Information: http://www.GHIJKL.com\n";
#else
#error Verify and update copyright/contact info in next versions
#endif

Another idea is to put a specific case in your bugtracker database in the
bottom of the backlog. Theoretically it should bubble up after some time
has passed.

Thanks, I'll see what I can do with that. It doesn't quite capture the idea
of "age", but maybe I can just have my build system define YEAR and MONTH
macros.

 

[Öö Tiib]

does anyone have a good method for determining if some code is
"expired"? Ideally, I could put something in the code like

#if __DATE__ > "01/01/2015"
#warning "Your code is old and is due for maintenance/rewrite"
#endif

But that obviously doesn't work. The idea is that in a couple years
I should at least /look/ at the code to see if it should be cleaned
up, refactored, etc.

How do people usually handle this?

There are other carriers of meta-information outside of source code.
For example location of all source code that I own is in repo. There are tons of meta-information that repo keeps.

If you are in same situation then you can schedule a script that regularly digs your repos and bugs you about notable statistics. Code that changes very often is likely crap and code that does not change at all is likely partof unused or forgotten feature/module. Therefore it is worth to report major deviations from normal (whatever it is for you) in both directions.

 

[Jorgen Grahn]

Hi all,
does anyone have a good method for determining if some code is "expired"? Ideally, I could put something in the code like

#if __DATE__ > "01/01/2015"
#warning "Your code is old and is due for maintenance/rewrite"
#endif

But that obviously doesn't work. The idea is
that in a couple years I should at least /look/ at the code to
see if it should be cleaned up, refactored, etc.

How do people usually handle this?

By doing nothing. In fact, I've never heard about it before, and it
never occured to me that you could see it that way. There's no expiry
date on source code. Not on C++, anyway.

The way I see it, the parts of the software which change a lot are the
ones where you should spend your energy. And of course the
troublesome ones with bugs or inconvenient interfaces.

I do agree with what someone else wrote though: there's a lot of
metadata in revision control, and (lack of) change is an interesting
part. If I need to maintain foo.cpp and am not familiar with it, I
will probably take a look at its change history very early. I can
also imagine going on a "guided tour" of the oldest parts of some
software I maintain, but it's not my highest priority.

/Jorgen

 

[Ian Collins]

Hi all, does anyone have a good method for determining if some code
is "expired"? Ideally, I could put something in the code like

#if __DATE__ > "01/01/2015" #warning "Your code is old and is due for
maintenance/rewrite" #endif

But that obviously doesn't work. The idea is that in a couple years I
should at least /look/ at the code to see if it should be cleaned up,
refactored, etc.

How do people usually handle this?

The general rule "if it ain't broke, don't fix it" usually applies!

I do have some low priority review/update tasks in my backlog which do
eventually bubble to the top. My usual reason to revisit old code is to
retire it. I've recently removed dependencies on and the source for a
number of utilities (my own shared pointer and thread wrappers for
example) that are now part of the standard library.

 

[woodbrian77]

Hi all,

does anyone have a good method for determining if some code is "expired"? Ideally, I could put something in the code like

#if __DATE__ > "01/01/2015"
#warning "Your code is old and is due for maintenance/rewrite"
#endif

But that obviously doesn't work. The idea is that in a couple years I should at least /look/ at the code to see if it should be cleaned up, refactored, etc.

How do people usually handle this?

I think you would have to be working for a good company
to get support for the idea. So I would advise to avoid
poorly managed companies.

Easier said than done? Agreed. I think it's gotten
more difficult today to find a decent company than it
used to be. Long term it might make sense to start
a company. Slow and steady wins the race. I think it
was Bill Buckley who said he would rather be governed
by the first 50 names in the Boston phone book than by
50 Harvard professors.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net