Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Get warned about old code

Reply
Thread Tools

Get warned about old code

 
 
Jonathan Lee
Guest
Posts: n/a
 
      10-16-2013
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
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      10-16-2013
On 10/16/2013 2:27 PM, Jonathan Lee wrote:
> 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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
 
 
 
Jonathan Lee
Guest
Posts: n/a
 
      10-16-2013
On Wednesday, October 16, 2013 3:04:19 PM UTC-4, Victor Bazarov wrote:
> 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.
 
Reply With Quote
 
Jonathan Lee
Guest
Posts: n/a
 
      10-16-2013
On Wednesday, October 16, 2013 2:48:09 PM UTC-4, Paavo Helde wrote:
> #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.
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      10-16-2013
On Wednesday, 16 October 2013 21:27:46 UTC+3, Jonathan Lee wrote:
> 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.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-16-2013
On Wed, 2013-10-16, Jonathan Lee wrote:
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-16-2013
Jonathan Lee wrote:
> 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.

--
Ian Collins
 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      10-17-2013
On Wednesday, October 16, 2013 1:27:46 PM UTC-5, Jonathan Lee wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can I get warned before rebooting if someone has a file open on my machine? Steve Freides Computer Support 7 02-25-2009 02:18 AM
beware of VONAGE! Don't sign up! I whish someone had warned me... big D VOIP 8 06-13-2006 05:28 AM
Be Warned CBIC MCSE 21 10-11-2005 04:54 PM
Got warned by my ISP... Sigi Rindler Computer Support 1 08-11-2005 12:08 PM
Be warned Gort Computer Support 1 08-25-2004 07:20 PM



Advertisments