Refactoring (was: Spacing conventions)

[Chris Angelico]

On Sat, Sep 30, 2017 at 12:45 AM, Stefan Ram <ram at zedat.fu-berlin.de> wrote:
> Chris Angelico <rosuav at gmail.com> writes:
>>If the behaviour remains *exactly* the same, then it's a code
>>improvement (aka a refactoring), not a bug fix.
>
>   Usually, one cannot observe whether behavior stays the same,
>   because a program does not map to behavior, but rather to an
>   entity that produces behavior during an /interaction/ with
>   the world.

And that's why you read source code.

>   For example, I can change
>
> x=float(input()); print( x * 2 )
>
>   to
>
> x=float(input()); print( x * 2 ) \
> if not __import__('random').random() == x else 0
>
>   . The new code has not the same "behavior" in a certain
>   sense. But what do we mean by "behaviour" here? Not
>   something one actually can observe! Because whenever
>   I start the program it behaves just as before the change.

That's also true of a lot of actual real-world bug fixes, though.
Programs don't tend to have as many glaringly obvious bugs as they
have little subtle issues or edge cases. Imagine fixing something that
only occurs if the computer's clock is in the middle of a DST fold and
then you change timezone, for instance. That's about as likely as the
example you give. But it's still not refactoring - refactoring is
where there is not meant to be ANY behavioural change at all.

ChrisA