Refactoring In Various Languages

 Q: "Is it possible to do refactoring in language 'X'?"
 A: "Yes."  (And it doesn't matter what 'X' is.)

Discussion of refactoring in various implementation languages:

VisualBasic: RefactoringInVisualBasic
SQL (StructuredQueryLanguage) -> RefactoringWithRelationalDatabases
C++ (CeePlusPlus): RefactoringWithCeePlusPlus
Python (PythonLanguage): RefactoringWithPython

It's been my experience that you can refactor in any language. Now some languages are not very expressive, so refactoring can be limited, but it's always possible. Object oriented languages like the SmalltalkLanguage and C++ (CeePlusPlus) are powerful tools, and provide lots of opportunities to improve the structure of code through refactoring. Procedural languages like COBOL, C and Transact-SQL (stored procedure language for Sybase and SQL Server) limit your ability to refactor. But there's often plenty of room for improvement, even when limited to strictly procedural code: You can rename procedures and variables to make them more clear. You can move global variables into parameters.

Never give up; there's always hope! ;-> -- JeffGrigg

T-SQL on its own has little structure, but in combination with the database it inhabits and the code which calls it, there is plenty of scope e.g. moving all SQL code into stored procedures is a desirable refactoring. -- AnonymousDonor

Refactoring within Transact-SQL can be quite limited.

I was working on a project in 1992 where so much business logic was embedded in triggers and the stored procedures they called, that we hit both size and depth limits of Transact-SQL calls. (Most databases have vaguely documented size limitations for stored procedures. Sybase had a documented calling depth limit of 16 calls, but would get real flaky after about 12.)

The whole project was a silly idea. ...and putting the entire accounting system into triggers was just one of the funnier parts. ;-> -- JeffGrigg

Grim. SQL is crap at business logic and triggers are a good way of making your system single-user. Fun when all your state changes are scattered around the place. I see a similar problem with some fundamentalist OO techniques. Massive trees of state-orientated objects with no central coordination, just brutal locking.

I look at refactoring as very much an architectural process. Code on its own doesn't drive a refactoring. Something else does, usually some architectural constraint which is failing. Therefore SQL is extensively refactored for performance, if not for beauty and adherence to OoWei. This includes consideration of the data structures (as tables and indexes), their physical devices etc. The location of the code may be important to ensure low-bandwidth physical channels are aligned with low volume logical interfaces. And so on. Maybe this is not what you mean by refactoring. If it is, then SQL is extensively refactored code in an application beyond the initial development. Most other code is added. High performance, high quality persistence is hard, and the best way to get it is by refactoring your SQL and data structures appropriately. There are many tips and tricks to be found. Like not putting logic in triggers ;). --RichardHenderson.

[CategoryRefactoring]