Updated 2012-07-09 10:44:39 by RLE

Refactoring is the process of changing the structure (or design) of code without changing the function. See these interesting references for discussions about refactoring.







One common approach for refactoring Tcl code is to repackage groups of functions into namespaces and packages. This modularization can improve the code maintainability, and it is very easy to do. See How to build good packages, and the cannonical reference by Will Duquette http://www.wjduquette.com/tcl/namespaces.html


ActiveState's Komodo and Red Hat's Source Navigator (see [1] and [2] ) both have project browsing capability for Tcl, although they aren't specifically for refactoring.

TV Without question an interesting subject, as it is in ordinary and advanced mathematics.

The terminology and practical meaning can be a bit confusing, I guess. Refactoring means reorganizing a function by rearranging its subfunctions by using its distributive properties and maybe substitution of its components. As a mathematician would reorder parentesis and arrive at a more compact or manageable or more workable organisation of an expression.

A compiler (for instance a C compiler) or linker (and in some cases and assembler) also can effectively do refactoring, and the whole idea of reusing functions and linking them into code is a process of using factors in the long list of the whole program. Especially compiler optimisatons are remindfull of refactoring, by expanding subexpressions, or performing substitutions to make code more volume or execution speed efficient.

In current programming approaches, a lot of things are called by a certain name, and organized into groups, in some way hierarchically or simply because there are many names used in a program. The organizing of all distinct names can be done in various ways, humanly speaking probably in some associative manner, which can be formulated mathematically, but is probably aimed at a process in (human) programmers minds and imaginations as not strictly a mathematical (re-)factoring process.

How does one organize the number of associations in a program where a lot of names are used in a handy, effective, and possibly generally applicable way?

This leads probably primarily and fundamentally to the question what can be mathematically or otherwise said with certainty about computer programs and data and their structure.

So I'm making a page mathematical foundation of computers and programs, for some without question well known, for others no doubt not very clear.

As a rule of the thumb, one gathers something when it is multiple somehow and gives it an overhead which is small in comparison with the existing data. At least then one doesn't need to think about it. Pointer and class hierarchy structures and library use without question regularly do not honour such basic ideas.

RS would start with drawing an UML-like chart to make clear what has to do with what.