Home > Archive > Extreme Programming > April 2008 > C Refactorings
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| pingu219 2008-03-27, 4:46 am |
| Hi I'm currently a student working on an honours-level project to
create a visual tool which will be able to represent C project files
and code as well as allow the user to perform high and certain low-
level refactorings.
At the moment I'm compiling a list of refactorings which are
applicable to C that people who program alot with structured
programming languages may find useful.
So far I've got (some I got from someone else's post on another google
group):
- Rename variable/function
- Move variable/function
- Reduce scope of variable
- Publish function (make it public, put a declaration in the .h file)
- Perish function (make it static, remove it from the .h file)
- Add/Remove parameter from function
- Reorder function arguments
- Remove unnecessary includes
Cheers!
| |
| Phlip 2008-03-27, 10:12 pm |
| pingu219 wrote:
> Hi I'm currently a student working on an honours-level project to
> create a visual tool which will be able to represent C project files
> and code as well as allow the user to perform high and certain low-
> level refactorings.
You might soon discover why nobody generally tries to do this.
> At the moment I'm compiling a list of refactorings which are
> applicable to C that people who program alot with structured
> programming languages may find useful.
C is (should be!) only used in super-high performance situations. The language
constantly risks undefined behavior, exchanging slow development time for fast
executable time and small footprint.
An ordinary refactoring tool depends on soft code where any compilable
expression is a legal expression. Casually speaking, a refactor preserves
testable behaviors, such that your tests will pass both before, during, and
after the operation. A C refactoring tool would have the incomprehensible burden
of preserving all kinds of untestable behavior, without creating undefined
behaviors.
> - Rename variable/function
> - Move variable/function
> - Reduce scope of variable
> - Publish function (make it public, put a declaration in the .h file)
> - Perish function (make it static, remove it from the .h file)
> - Add/Remove parameter from function
> - Reorder function arguments
> - Remove unnecessary includes
Get with John Lakos's work with large scale C++ software design, including any
drafts for a new book I heard he's working on.
And you should start with the Refactoring book for your list. You seem to be
missing the most important ones - the Extracts. Extract Local Variable, Extract
Method, and Extract Class are the heart of emergent design. Yet a true Extract
should find _each_ call site for its extractee, and introduce a call there. That
would be extremely hard in C - under macro abuse and such - so I think that's
why they are not on your list.
--
Phlip
| |
| Jim Kingdon 2008-03-27, 10:12 pm |
| > That would be extremely hard in C - under macro abuse and such - so I
> think that's why they are not on your list.
Yeah, macro abuse is the usual reason given for the lack of
refactoring tools for C.
I suspect the real reason is more that C programmers don't want
refactoring tools as much as for some languages. Sure, macros are a
problem, but most refactoring tools don't try to be perfect, so I
start with the easy cases.
After all, languages like Ruby have at least as many challenges for
refactoring tools (not the same challenges as C, however), but the
refactoring tools exist.
| |
|
| Jim Kingdon wrote:
>
> Yeah, macro abuse is the usual reason given for the lack of
> refactoring tools for C.
If that were the end of it...
int x[42][2];
memset(x, 0, sizeof x);
x[0][13] = 1;
C exists to permit abuses like those. It is portable assembler. You code to
a virtual machine, with enforced standards such as "contiguous arrays".
--
Phlip
| |
| pingu219 2008-04-01, 7:11 pm |
| Thanks for the replies
The reason my list of refactorings was limited is because I will
mostly only be featuring refactorings which don't take place within a
function, as it would be abit difficult to integrate the internals of
a function visually for display and manipulation with my graphical
tool. Only problem is now my list of refactorings seems -too- limited.
|
|
|
|
|