Description Dekel 2008-12-26 17:02:37 EST

Problem: Often, developers encounter overly complicated boolean expression/logic, resulting in one or several of the following:
1) Unneeded boolean variables or conditional branches.
2) Deep nesting of if-then-else statements
3) Large expressions, with many operators
4) Overuse of negation, which is confusing.

See examples in http://invisibleblocks.wordpress.com/2008/12/24/simplifying-boolean-expressions/
and its outgoing links.

Scenarios:
A) Developer reads other-people-code and needs to simplify to better understand it. In this scenario, 
B) Developer writes a new code, and decides to refactor to make it more understandable (maintainable).

Suggested Solution:
New Refactoring(s) to handle common cases.
a) There may be cases when the user have to input (UI) parameters, since she prefers one kind of simplification over another. This can also result in a separate refactoring.
b) For scenario A, the developer doesn't want to permanently change the sources, and may not even have a write permission without checking out (Ex: clearcase), so the real requirement here is view of a transformed source-code for short period of time and not refactoring.
One way to implement that, is to refactor and then undo, but that seems a little bit "mutable" for the "readonly" requirement.

Note that the "view of a transformed source-code" for code understanding may be useful for many other transforms.