Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #7499 > unrolled thread

Refactoring strategy

Back to article view | Back to comp.programming

Contents

  Refactoring strategy Victor Porton <porton@narod.ru> - 2017-03-08 21:34 +0200
    Re: Refactoring strategy Julio Di Egidio <julio@diegidio.name> - 2017-03-08 12:04 -0800

#7499 — Refactoring strategy

I was assigned to refactor several similar functions, namely extract common 
code fragments for no repetition.

The main problem is to pass long lists of variables and references to 
variables into the "fragment" functions.

I propose the following as a solution:

Replace all (or most of) local variables with members of a record/structure 
(actually hash in Perl) members. Let call this structure $Values.

Then I pass a reference to the structure into fragment functions instead of 
passing all variables separately.

But actually I also make a copy of $Params hash (which contains most 
function parameters). In the old code local variables were created from this 
hash like:

my $Site = $Params->{Site} || '';

(For these who don't know Perl, it means to put the value of {Site} 
parameter from the hash $Params into $Site variable, using empty string 
instead of null (`undef` in Perl) value.)

To overcome this, I first make a copy of $Params:

my %ParamsCopy = %$Params;

and then modify it inplace:

$ParamsCopy{Site} ||= '';

Any comments are welcome.

Particularly, I question: Is it worth to merge $ParamsCopy and $Values into 
one structure instead of two?

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#7500

On Wednesday, March 8, 2017 at 8:34:56 PM UTC+1, Victor Porton wrote:

> I was assigned to refactor several similar functions, namely extract
> common code fragments for no repetition.

The customer is always right, and the hype, but, so that you know, the
technically correct term is "restructuring".

> The main problem is to pass long lists of variables and references to 
> variables into the "fragment" functions.

Speaking in general, restructuring is more than just extracting out code
duplication.  You are supposed to rationalise the whole thing really.

> I propose the following as a solution:
> 
> Replace all (or most of) local variables with members of a record/structure 
> (actually hash in Perl) members. Let call this structure $Values.
> 
> Then I pass a reference to the structure into fragment functions instead of 
> passing all variables separately.

With the above proviso, this is fine.

> But actually I also make a copy of $Params hash (which contains most 
> function parameters). In the old code local variables were created from this 
> hash like:
> 
> my $Site = $Params->{Site} || '';
> 
> (For these who don't know Perl, it means to put the value of {Site} 
> parameter from the hash $Params into $Site variable, using empty string 
> instead of null (`undef` in Perl) value.)
> 
> To overcome this, I first make a copy of $Params:
> 
> my %ParamsCopy = %$Params;
> 
> and then modify it inplace:
> 
> $ParamsCopy{Site} ||= '';
> 
> Any comments are welcome.
> 
> Particularly, I question: Is it worth to merge $ParamsCopy and $Values
> into one structure instead of two?

If really every parameter becomes a local variable, i.e. there is no
added semantics to the local state or similar, then yes.

Julio

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web