Exploring Extreme Programming
Immutability is the idea that once created, data never changes. Why might we want this? Avoid aliasing bugs: Aliasing occurs when there are multiple ways to access the same piece of data, and one piece changes it in a way Continue reading Immutable Objects
Functional languages often have immutable data types – you can’t change an object once you’ve created it, though you can include it as part of other objects. Immutable objects are easier to reason about, and prevent errors where two parts Continue reading Queues from Stacks: Functional Data Types
Refactoring improves the design of code without changing its observable behavior. But what is observable behavior? We’ll look at how language semantics affect that. When you devise new refactorings, you have to take semantics into account. The Simple View is Continue reading Refactoring and Programming Language Semantics
Coupling occurs when one part of a system depends on another part. That is, if one part changes, the other must be adjusted too. Lambda expressions can reduce coupling by needing to refer to fewer things. Dependencies on Objects Consider Continue reading Lambda to Reduce Coupling
Automated refactoring tools are great, but sometimes the tool doesn’t make the best choice. We can often nudge the tool to a better choice. Why Bother? Why bother nudging? Couldn’t you do the refactoring manually just as quickly? You could Continue reading Refactoring: Forcing the Right Extract Method
Environments vary substantially between computers, so you’ll often see environment-specific code hidden in the PEEKs and POKEs of old BASIC programs. We’ll take a brief tour of the Ohio Scientific and Commodore 64, two computers from the late 1970s to Continue reading Ohio Scientific and Commodore 64 Environments
Once in a while, I run into a 1980s-era BASIC program, typically written for Commodore 64, Apple ][, or TRS-80. I’d like to transliterate it into a modern language, refactor it, and explore it. These old programs make a nice Continue reading Transliterating Old-School BASIC
When we create test data in TDD, we do it to drive out new capabilities. But all test data is not of the same value. If your data has the wrong symmetry, it can mislead you about what’s working. Object Continue reading Avoid Irrelevant Symmetry!
Some refactorings (e.g., Extract Method or Extract Class) introduce new elements. Should you revise the tests to take these into account? The classic consultant’s answer applies: It depends. The obvious next question is “Depends on what?”, and we’ll explore some Continue reading Revise Tests While Refactoring? It Depends
Objects usually track state, but you can instead track history and derive the current state from the history. (For example, databases blend both modes behind the scenes.) Why might history be helpful? One reason is that it can make it Continue reading Reversible, Incremental Data Structures