ITEM not available

Have a question for Kode Vicious? E-mail him at [email protected]. If your question appears in his column, we'll send you a rare piece of authentic Queue memorabilia. We edit e-mails for style, length, and clarity.

Comments

(newest first)

Volkan TUNALI | Mon, 30 Nov 2009 01:30:46 UTC

In the the article it looks maintenance is almost equal to refactoring. However, refactoring is not only part of maintenance; refactoring is a continuous effort through the development process. Thus, I think refactoring should not be taken as the equivalent of maintenance, or vice versa. Maintenance is the process of changing the system (software) after it is delivered and it is in use. Of course the process of maintenance includes bug-fixes in the code, fixes of errors in design, porting of software to different platforms (h/w or s/w), and adding new features. All those jobs cannot be regarded as only refactoring, and cannot be done just by refactoring.

Robert Taylor | Tue, 17 Nov 2009 16:15:53 UTC

Re:Maintenance

I'm not sure why anyone would have issues with being a bug fixer. I do it for mine and other staff's code. It's part of the process. The process is that of removing flaws and improving the system or adding needed function to an existing system. It is a different effort related to the original task. Maintenance is just a different form of problem solving but requires a slightly different outlook.

Andrew Dalke | Wed, 04 Nov 2009 12:32:11 UTC

The Python re module(s) has one case where #include:ing a C file makes sense. The _sre.c code implements the re engine for 8-bit byte strings then sets up an #define and #include:s itself. The #define changes a few settings and does some conditional code to support 16-bit Unicode strings. Because most of the code between those two instances is identical, having one C file means there's less code and less code duplication, at the cost of this recursive #include.

I've also used #include to bring in a section of code which was machine-generated, in my case a set of precomputed data tables. As you write, this can be replaced with a linker, but I figured I didn't want another global symbol and by using #include I can keep it in the same compilation unit.

John Ahlstrom | Mon, 31 Aug 2009 22:17:08 UTC

Software engineers (or their bosses) are the only ones who would call adding an upper deck to the Golden Gate Bridge "maintenance". -- unknown

Samuel Bronson | Fri, 28 Aug 2009 02:53:36 UTC

Well, that's a bit different -- for one thing, you're hardly going to miss the #includes when the file contains nothing else except comments and whitespace ...

Paul Lalonde | Sat, 22 Aug 2009 22:27:08 UTC

There is a situation where #include of a C file is valuable. Some (many? most?) build systems can't aggregate multiple source files to pass to the compiler at once, leading to compiler invocation overhead for each C file - this can slow your build dramatically. One work-around is to include all the C source files for one library into one C file; I've seen build times go up an order of magnitude using this technique. Yes, it's better to have your build system do this, and you only want to do it when your build times have been crawling up towards unacceptable. And you had better document why you did it. Caveat emptor.

Leave this field empty

Post a Comment:

Comment: (Required - 4,000 character limit - HTML syntax is not allowed and will be removed)