Repository files navigation

• Introduction
• Elixir-Specific Refactorings
  • Alias expansion¹
  • Default value for an absent key in a Map¹
  • Defining a subset of a Map¹
  • Modifying keys in a Map¹
  • Simplifying Ecto schema fields validation¹
  • Pipeline using "with"¹
  • Pipeline for database transactions¹
  • Transform nested "if" statements into a "cond"¹
  • Explicit a double boolean negation¹
  • Transform "if" statements using pattern matching into a "case"¹
  • Moving "with" clauses without pattern matching¹
  • Remove redundant last clause in "with"²
  • Replace "Enum" collections with "Stream"²
  • Generalise a process abstraction²
• Traditional Refactorings
  • Rename an identifier
  • Moving a definition
  • Add or remove a parameter
  • Grouping parameters in tuple
  • Reorder parameter
  • Extract function
  • Inline function
  • Folding against a function definition
  • Extract constant
  • Temporary variable elimination
  • Extract expressions
  • Splitting a large module
  • Remove nested conditional statements in function calls
  • Move file
  • Remove dead code
  • Introduce a temporary duplicate definition
  • Introduce overloading
  • Remove import attributes
  • Introduce import
  • Group Case Branches
  • Move expression out of case
  • Simplifying checks by using truthness condition¹
  • Reducing a boolean equality expression¹
  • Transform "unless" with negated conditions into "if"¹
  • Replace conditional with polymorphism via Protocols¹
• Functional Refactorings
  • Generalise a function definition
  • Introduce pattern matching over a parameter
  • Turning anonymous into local functions
  • Merging multiple definitions
  • Splitting a definition
  • Inline macro
  • Transforming list appends and subtracts
  • From tuple to struct
  • Struct guard to matching
  • Struct field access elimination
  • Equality guard to pattern matching
  • Static structure reuse
  • Simplifying guard sequences
  • Converts guards to conditionals
  • Widen or narrow definition scope
  • Introduce Enum.map/2
  • Merging match expressions into a list pattern
  • Function clauses to/from case clauses
  • Transform a body-recursive function to a tail-recursive
  • Eliminate single branch
  • Transform to list comprehension
  • Nested list functions to comprehension
  • List comprehension simplifications
  • Closure conversion³
  • Replace pipeline with a function¹
  • Remove single pipe¹
  • Simplifying pattern matching with nested structs¹
  • Improving list appending performance¹
  • Convert nested conditionals to pipeline¹
  • Replacing recursion with a higher-level construct¹
  • Replace a nested conditional in a "case" statement with guards²
  • Replace function call with raw value in a pipeline start²
• Erlang-Specific Refactorings
  • Typing parameters and return values
  • Moving error-handling mechanisms to supervision trees
  • From meta to normal function application
  • Remove unnecessary calls to length/1
  • Add type declarations and contracts
  • Introduce processes
  • Remove processes
  • Add a tag to messages
  • Register a process
  • Behaviour extraction
  • Behaviour inlining
• About
• Acknowledgments

Elixir is a functional programming language whose popularity is on the rise in the industry^link. As no known studies have explored refactoring strategies for code implemented with this language, we reviewed scientific literature seeking refactoring strategies in other functional languages. The found refactorings were analyzed, filtering only those directly compatible or that could be adapted for Elixir code. As a result of this investigation, we have initially proposed a catalog of 55 refactorings for Elixir systems.

Afterward, we scoured websites, blogs, forums, and videos (grey literature review), looking for specific refactorings for Elixir that its developers discuss. With this investigation, the catalog was expanded to 76 refactorings. Finally, 6 new refactorings emerged from a study mining software repositories (MSR) performed by us, so this catalog is constantly being updated andcurrently has 82 refactorings. These refactorings are categorized into four different groups (Elixir-specific,traditional,functional, andErlang-specific), according to the programming features required in code transformations. This catalog of Elixir refactorings is presented below. Each refactoring is documented using the following structure:

• Name: Unique identifier of the refactoring. This name is important to facilitate communication between developers;
• Category: Scope of refactoring in relation to its application coverage;
• Motivation: Description of the reason why this refactoring should be done and what this refactoring does to the code;
• Examples: Illustrates the resulting code from the refactoring, showing versions of it before and after the transformation;
• Side-conditions (*): Minimum requirements to perform refactoring without creating conflicts with other parts of the code that may depend on the transformations promoted;
• Mechanics (*): Sequence of main steps for the promoted code transformations.

Note: (*) not all refactorings have explicit definitions for these fields.

Tool support:RefactorEx is a VS Code extension inspired by this catalog that can semi-automatically apply some of the refactoring strategies defined here. Please take a look!

This catalog of refactorings aims to improve the quality of code developed in Elixir, helping developers promote the redesign of their code, making it simpler to understand, modify, or even improving performance. These transformations must be performed without changing the original behavior, thus preserving the code's functionality. For this reason, we are interested in knowing Elixir's community opinion about these refactorings:Do you agree that these refactorings can be useful? Have you seen any of them in production code? Do you have any suggestions about some Elixir-specific refactorings not cataloged by us?...

Please feel free to make pull requests and suggestions (Issues tab). We want to hear from you!

▲ back to Index

Elixir-specific refactorings are those that use programming features unique to this language. In this section, 14 different refactorings classified as Elixir-specific are explained and exemplified:

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: In Elixir, when using analias for multiple names from the same namespace, you can sort and consolidate them within a single file, reducing redundancy. Although this programming practice is common and can reduce the number of lines of code, multi-aliases can make it harder to search for a dependency in large code bases. This refactoring aims to expand multi-alias instructions fused into one multi-instruction per namespace, transforming them into single alias instructions per name. This provides improvement in code readability and traceability.

• Examples: In the following code, before refactoring, we have a multi-alias instruction combining the definition of two dependencies. In this particular case, the dependencies for theBaz andBoom modules were merged into a single instruction.

  # Before refactoring:aliasFoo.Bar.{Baz,Boom}

  Especially in larger code bases, involving a greater number of dependencies within the same namespace (nested modules), the definition of these aliases could be refactored by analias expansion, better highlighting all dependencies, as shown in the following code.

  # After refactoring:aliasFoo.Bar.BazaliasFoo.Bar.Boom

  This example is derived from code found in the official documentation for the toolsRecode andExactoKnife.

• Side-conditions:

  • The number ofalias commands inserted by this refactoring is identical to the number of modules that were originally merged into a singlealias instruction (i.e., inside a{}, such as{Baz, Boom});

  • Each of thealias instructions inserted by this refactoring should start with the path that was shared by the modules originally merged (e.g.,Foo.Bar), followed by a. and the name of one of the modules that were previously imported by a single command (e.g.,Bar orBoom).

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: We often come across a situation where we expect aMap to have a certain key, and if not, we need to provide a default value. A commonly used alternative for such situations is using the built-inMap.has_key?/2 function along with anif...else statement. Although this alternative works perfectly, it's possible to refactor this code using only the built-inMap.get/3 function, making the code less verbose and more readable, while preserving the same behavior.

• Examples: In the following code, before refactoring, we utilize theMap.has_key?/2 function in conjunction with anif...else statement to retrieve the currency from aMap containing the price of a product. If thecurrency key does not exist, we return the default value of"USD".

  # Before refactoring:currency=if(Map.has_key?(price,"currency"))doprice["currency"]else"USD"

  Applying this refactoring, the above code can be transformed into the following code, preserving the behavior while reducing the number of lines.

  # After refactoring:currency=Map.get(price,"currency","USD")

  This example is based on an original code by Malreddy Ankanna. Source:link

• Side-conditions:

  • To be eligible for this refactoring, the code snippet must consist of anif..else statement, where the condition checked is a call to the built-in functionMap.has_key?/2. Additionally, the branch created by theif should only return the value of the key in theMap whose existence was checked by the call toMap.has_key?/2, while the branch defined by theelse should only return a default value for a non-existent key.

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: When dealing with hugeMap structures, there are occasions when we need to extract a subset of elements to form a newMap. Instead of manually creating this subset by individually accessing each of the desired key/value pairs from the originalMap, with this refactoring, we can simply use the built-inMap.take/2 function.

• Examples: In the following code, we have a variablepickup bound to aMap composed of a huge number of keys.

  # Huge Mappickup=%{"zip"=>"75010","town"=>"PARIS","stopName"=>"RECEPTION","pickupId"=>4018,"longitude"=>2.360982,"latitude"=>48.868502....#a lot of keys}

  To extract only the metadata related to location, before refactoring, we manually access the values identified by the keys"latitude" and"longitude" to then create a newMap.

  # Before refactoring:longitude=pickup["longitude"]latitude=pickup["latitude"]location=%{# <-- Defining a subset manually"longitude"=>longitude,"latitude"=>latitude}

  Although this solution works, it can generate a significant amount of code, primarily due to duplications. Applying this refactoring, we can eliminate duplicated code, significantly reducing the number of lines and improving readability.

  # After refactoring:location=Map.take(pickup,["latitude","longitude"])

  This example is based on an original code by Malreddy Ankanna. Source:link

• Side-conditions:

  • To be eligible for this refactoring, the code snippet must originally create a subset of aMap manually, meaning it constructs a newMap containing only some of the key/value pairs from the completeMap;

  • The number of elements in the list passed as the second parameter of theMap.take/2 call in the refactored version of the code must be identical to the number of key/value pairs that originally composed the manually created subset. Additionally, the elements of this list must be exactly the keys of that subset.

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: Sometimes we need to update the format of aMap, replacing the name given to a key but keeping the new key name associated with the original value. Instead of usingMap.get/2,Map.put/2, andMap.delete/2 functions together, which involves a lot of manual work and generates many lines of code, we can simply use the built-inMap.new/2 function along with the use of multi-clause lambdas. This refactoring can significantly reduce the volume of lines of code, eliminating duplicated code and even making the code more resilient to typing-related errors.

• Examples: In the following code, we have a variablepickup bound to aMap.

  pickup=%{"stopName"=>"RECEPTION","pickupId"=>4018,"longitude"=>2.360982,"latitude"=>48.868502}

  Let's suppose we want to change the name of the key"latitude" to simply"lat", while keeping the rest of theMap unchanged. The following code, before refactoring, performs this task manually. It first retrieves the value associated with the"latitude" key, then creates a new key called"lat" and associates it with the extracted value from the"latitude" key. Finally, the"latitude" key is removed from theMap.

  # Before refactoring:latitude=Map.get(pickup,"latitude")# --> step 1pickup=Map.put(pickup,"lat",latitude)# --> step 2pickup=Map.delete(pickup,"latitude")# --> step 3

  Although this solution works, imagine a situation where many keys need to be updated in aMap. The manual strategy presented above can become cumbersome and impractical. By using the built-inMap.new/2 function, this refactoring would make it easier to simultaneously update the format of all keys in theMap, as shown in the following code.

  # After refactoring:pickup=Map.new(pickup,fn{"latitude",lat}->{"lat",lat}{key,value}->{key,value}# <-- Clause for unchanged keysend)

  This example is based on an original code by Malreddy Ankanna. Source:link

• Side-conditions:

  • To be eligible for this refactoring, the code snippet must originally be composed of a call to the functionMap.get/2, followed byMap.put/2, andMap.delete/2;

  • All temporary variables created in the refactored version for performing pattern matching in clauses of the multi-clause anonymous function (e.g.,lat,key, andvalue) must have names different from other previously defined variables, thus avoiding conflicts;

  • The multi-clause anonymous function passed as a parameter to theMap.new/2 call in the refactored version must have at least two clauses: one for each modified key (e.g.,{"latitude", lat} -> {"lat", lat}) and another to keep all other keys unchanged as in the original (i.e.,{key, value} -> {key, value}).

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: After defining a schema in Ecto, it's common to need to group fields for validations, such as those performed by the Ecto validatorvalidate_required/3. However, if we attempt to perform this grouping by manually implementing a list, there's a risk of making the code overly verbose, prone to typographical errors, and even subject to rework if the schema is modified in the future. Instead of relying on manually created lists, we can simply use the Ecto__schema__/1 function, which returns the list of fields in the schema. With this refactoring, we can simplify the code, making it less prone to errors and more maintainable.

• Examples: In the following code, we have an Ecto schema composed by six fields.

  embedded_schemadofield:carrier_time,:stringfield:carrier_date,:stringfield:carrier_name,:stringfield:carrier_number,:stringfield:carrier_terminal,:stringfield:carrier_type,:stringend

  The following code manually lists in theschema_fields variable all the fields in our schema that will be validated by the Ectovalidate_required/3 function. Note that this listing process can be cumbersome, prone to typographical errors, and furthermore, it generates duplicated code.

  # Before refactoring:defchangeset(attrs)do# Manual listing of schema fieldsschema_fields=[:carrier_time,:carrier_date,:carrier_name,:carrier_number,:carrier_terminal,:carrier_type]%__MODULE__{}|>cast(attrs,schema_fields)|>validate_required(schema_fields,message:"Missing Field")end

  We can refactor the field listing by replacing the manual list with a call to the Ecto__schema__/1 function. When we call this function with the atom:fields as a parameter, it returns the list of all non-virtual field names, which is exactly the same list we created manually before the refactoring.

  # After refactoring:defchangeset(attrs)doschema_fields=__schema__(:fields)#<-- returns dynamically the list of schema fields!%__MODULE__{}|>cast(attrs,schema_fields)|>validate_required(schema_fields,message:"Missing Field")end

  Although simple, this refactoring brings many improvements to the code quality. If the database schema is altered, for instance, the above code will continue to work for all fields in the schema without the need for additional modifications.

  This example is based on an original code by Malreddy Ankanna. Source:link

• Side-conditions:

  • To be eligible for this refactoring, the code snippet must originally contain a manually created list being passed as a parameter to a call to thevalidate_required/3 function;

  • If the original list does not contain all the fields of an Ecto schema, the refactored version should perform a list subtraction (i.e.,Kernel.--/2) on the result of the__schema__/1 function call. For example, if the original list includes all fields except:carrier_terminal and:carrier_type, to maintain the same behavior, the following expression should be used:__schema__(:fields) -- [:carrier_terminal, :carrier_type].

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: When conditional statements, such asif..else andcase, are used in a nested manner to create sequences of function calls, the code can become confusing and have poor readability. In these situations, we can replace the use of nested conditionals with a kind of function call pipeline using awith statement. This refactoring enforces the use of pattern matching at each function call, interrupting the pipeline if any pattern does not match. Additionally, it has the potential to enhance code readability without modifying the signatures (heads) of the involved functions, making this refactoring less prone to breaking changes compared toConvert nested conditionals to pipeline.

• Examples: In the following code, the functionupdate_game_state/3 uses nested conditional statements to control the flow of a sequence of function calls tovalid_move/2,players_turn/2, andplay_turn/3. All these sequentially called functions have a return pattern of{:ok, _} or{:error, _}, which is common in Elixir code.

  # Before refactoring:defpupdate_game_state(%{status::started}=state,index,user_id)do{move,_}=valid_move(state,index)ifmove==:okdoplayers_turn(state,user_id)|>casedo{:ok,marker}->play_turn(state,index,marker)other->otherendelse{:error,:invalid_move}endend

  Note that, although this code works perfectly, the nesting of conditionals used to ensure the safe invocation of the next function in the sequence makes the code confusing. Therefore, we can refactor it by replacing these nested conditional statements with a pipeline that uses awith statement, thereby reducing the number of lines of code and improving readability, while keeping the behavior and signature of all the involved functions intact.

  # After refactoring:defpupdate_game_state(%{status::started}=state,index,user_id)dowith{:ok,_}<-valid_move(state,index),{:ok,marker}<-players_turn(state,user_id),{:ok,new_state}<-play_turn(state,index,marker)do{:ok,new_state}else(other->other)endend

  As is characteristic of thewith statement, the next function in this pipeline will only be called if the pattern of the previous call matches. Otherwise, the pipeline is terminated, returning the error that prevented it from proceeding to completion. Note that this refactored version, although functioning correctly, also presents an opportunity to apply the refactoringRemove redundant last clause in "with", since the last clause of thewith statement is composed of a pattern identical to the predefined value to be returned by thewith in case all checked patterns match.

  This example is based on an original code by Gary Rennie. Source:link

• Side-conditions:

  • To be eligible for this refactoring, each of the functions called sequentially within a nested conditional must originally have their execution flow controlled by some form of pattern matching. For example, functions that return values in the format{:ok, _} or{:error, _} are candidates for having their sequential calls refactored;

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: TheEcto.Repo.transaction/2 function allows performing operations on the database, such as update and delete. The first parameter of this function can be an anonymous function or a data structure calledEcto.Multi. When we want to perform a sequence of operations on the database using only one call toEcto.Repo.transaction/2, the use of an anonymous function as the first parameter of this function can impair code readability, making it confusing. This refactoring converts anonymous functions used to create a pipeline of operations into calls toEcto.Repo.transaction/2, transforming them into instances ofEcto.Multi, a data structure used for grouping multiple Repo operations. The code generated by this refactoring becomes cleaner and, furthermore, it does not allow the execution of operations if theEcto.Multi is invalid (i.e., if any of the changesets have errors).

• Examples: In the following code, the functionclear_challenges/2 makes a call toEcto.Repo.transaction/2 aiming to execute a sequence of update and delete operations on the database.

  # Before refactoring:defupdate_refused_challenges(user,count)doparams=%{refused_challenges:user.refused_challenges+count}user|>User.update_changeset(params)|>Repo.update()enddefpdelete_challenges(challenges)doids=Enum.map(challenges,&(&1.id))query=where(Challenge,[c],c.idin^ids)Repo.delete_all(query)enddefpstop_games(challenges)doEnum.map(challenges,&GameRegistry.delete_game(&1.id))enddefclear_challenges(user,age\\300)dochallenges=get_old_open_challenges(user,age)count=length(challenges)Repo.transaction(fn->with{:ok,user}<-update_refused_challenges(user,count),delete_challenges(challenges),stop_games(challenges),do:user,else:({:error,reason}->Repo.rollback(reason))end)end

  Note that before the refactoring, this call toEcto.Repo.transaction/2 uses a complex anonymous function as its first parameter. This anonymous function employs awith statement to structure a pipeline of operations, similar toPipeline using "with". While this code works perfectly, in this context, we can enhance the readability of this database operations pipeline by replacing the anonymous function with theEcto.Multi data structure, specifically designed for creating such pipelines. The following code presents the refactored version of theclear_challenges/2 function.

  # After refactoring:defupdate_refused_challenges(user,count)doparams=%{refused_challenges:user.refused_challenges+count}user|>User.update_changeset(params)#|> Repo.update()   <-- removed during refactoring!enddefpdelete_challenges(challenges)doids=Enum.map(challenges,&(&1.id))query=where(Challenge,[c],c.idin^ids)# Repo.delete_all(query) <-- removed during refactoring!enddefpstop_games(challenges)doEnum.map(challenges,&GameRegistry.delete_game(&1.id)){:ok,:stopped_games}# <--- added during refactoring!enddefclear_challenges(user,age\\300)dochallenges=get_old_open_challenges(user,age)count=length(challenges)Ecto.Multi.new()|>Ecto.Multi.update(:user,update_refused_challenges(user,count))|>Ecto.Multi.delete_all(:challenges,delete_challenges(challenges))|>Ecto.Multi.run(:games,fn_->stop_games(challenges)end)|>Repo.transaction()end

  This example is based on an original code by Gary Rennie. Source:link

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: While code using nestedif statements works, it can be verbose and not very maintainable in some situations. Elixir doesn’t have anelse if construct, but it does have a statement calledcond that is logically equivalent. This refactoring aims to transform multiple conditionals, implemented using nestedif statements, into the use of acond statement, leaving the code without complex indentations and therefore cleaner and more readable.

• Examples: In the following code, theclassify_bmi/2 function uses several nestedif..else statements to classify the Body Mass Index (BMI) of an individual, calculated based on their weight and height.

  # Before refactoring:defclassify_bmi(weight,height)do{status,bmi}=calculate_bmi(weight,height)ifstatus==:okdoifbmi<18.5do"Underweight"elseifbmi<25.0do"Normal weight"elseifbmi<30.0do"Overweight"elseifbmi<35.0do"Obesity grade 1"elseifbmi<40.0do"Obesity grade 2"else"Obesity grade 3"endendendendendelse"Error in BMI calculation:#{bmi}"endend

  Although this code works well, it is unnecessarily large in terms of the number of lines, and it also has complex indentations, resulting in an unattractive and less maintainable appearance. In the following code, after refactoring the nestedif..else statements into an Elixircond statement, theclassify_bmi/2 function has a cleaner and more readable appearance.

  # After refactoring:defclassify_bmi(weight,height)do{status,bmi}=calculate_bmi(weight,height)ifstatus==:okdoconddobmi<18.5->"Underweight"bmi<25.0->"Normal weight"bmi<30.0->"Overweight"bmi<35.0->"Obesity grade 1"bmi<40.0->"Obesity grade 2"true->"Obesity grade 3"endelse"Error in BMI calculation:#{bmi}"endend

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: In Elixir, when we perform a double boolean negation, we cast anything truthy totrue and anything non-truthy tofalse. In other words, this will returnfalse forfalse andnil, andtrue for anything else. Although this approach may seem interesting initially, it can make the code less expressive by omitting the real intention of this operation. Therefore, to improve readability, we can replace double boolean negations by introducing a helper multi-clause function.

• Examples: In the following code, we can observe the behavior of double boolean negations applied to four distinct variables.

  # Before refactoring:var_1=truevar_2=falsevar_3=nilvar_4=100#...Use examples...iex(1)>!!var_1trueiex(2)>!!var_2falseiex(3)>!!var_3falseiex(4)>!!var_4true

  To make our code more expressive, we can refactor the operations above by creating a multi-clause function that uses pattern matching to map all the behavioral possibilities of a double boolean negation. Below, we demonstrate this refactoring by creating the functionhelper/1. Note that this name is purely illustrative, so the function could be renamed to something that better represents its purpose, depending on the context.

  # After refactoring:defmoduleFoododefhelper(nil),do:falsedefhelper(false),do:falsedefhelper(_),do:trueend#...Use examples...iex(1)>Foo.helper(var_1)trueiex(2)>Foo.helper(var_2)falseiex(3)>Foo.helper(var_3)falseiex(4)>Foo.helper(var_4)true

  These examples are based on code written in Credo's official documentation. Source:link

• Side-conditions:

  • The name and arity of function created in this refactoring (e.g.,helper/1) must not conflict with the name of any other function already defined or imported by the refactored module.

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: Pattern matching is most effective for simple assignments withinif andunless clauses. Although Elixir allows pattern matching in conditional tests performed by anif statement, it may compromise code readability when used for flow control purposes. If you need to match a condition and execute a different block when it's not met, it's advisable to use acase statement instead of combining pattern matching with anif statement. This refactoring, therefore, aims to carry out this type of code transformation.

• Examples: In the following code, anif statement is used in conjunction with pattern matching. In this situation, thedo_something/1 function is called if the pattern matches.

  # Before refactoring:if{:ok,contents}=File.read("foo.txt")dodo_something(contents)end

  As shown in the following code, we can refactor the previous code by replacingif statements that use pattern matching with an Elixircase statement, which is a more appropriate conditional for working alongside pattern matching. This refactoring also makes the code more flexible for future changes, as it opens the possibility to execute different code blocks when a pattern does not match, something that would not be possible using only anif..else statement.

  # After refactoring:caseFile.read("foo.txt")do{:ok,contents}->do_something(contents)_->do_something_else()end

  These examples are based on code written in Credo's official documentation. Source:link

• Side-conditions:

  • This refactoring is free of side-conditions and can therefore be applied whenever anif statement performing pattern matching in its condition is selected.

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: Usingwith statements is recommended when you want to string together a series of pattern matches, stopping at the first one that fails. Although is possible to define awith statement using an initial or final clause that doesn't involve a<- operator (i.e., it doesn't match anything), it fails to leverage the advantages provided by thewith, potentially causing confusion. This refactoring aims to move these clauses that don't match anything to outside thewith statement (for the initial ones) or place them inside the body of thewith statement (for the final ones), thereby enhancing the code's focus and readability.

• Examples: In the following code, we have awith statement composed of four clauses. As we can observe, the first and last clauses do not involve matching specific patterns. In other words, they do not use the<- operator.

  # Before refactoring:withref=make_ref(),{:ok,user}<-User.create(ref),:ok<-send_email(user),Logger.debug("Created user:#{inspect(user)}")douserend

  To enhance the readability of our code, keeping the clauses of thewith statement focused solely on performing a pipeline of pattern matching, we can move the first clause of this code outside of thewith statement and the last clause to inside its body, as shown in the following code. Note that although these clauses have been moved, the behavior of the code remains unchanged.

  # After refactoring:ref=make_ref()# moved outside of the 'with'with{:ok,user}<-User.create(ref),:ok<-send_email(user)doLogger.debug("Created user:#{inspect(user)}")# moved inside the body of the 'with'userend

  These examples are based on code written in Credo's official documentation. Source:link

• Side-conditions:

  • The first and/or last clause of thewith statement to be refactored should not use the<- operator (i.e., they don't match anything).

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Mining Software Repositories (MSR) study.

• Motivation: When the last clause of anwith statement is composed of a pattern identical to the predefined value to be returned by thewith in case all checked patterns match, this clause is consideredredundant. In such situations, this last clause of thewith can be removed, and the predefined value to be returned by thewith should then be replaced by the expression that was checked in the redundant clause that was removed. This refactoring will maintain the same behavior of the code while making it less verbose and more readable.

• Examples: In the following code, the callbackhandle_call/3 uses awith statement with a redundant last clause. Note that the pattern compared in the last clause is identical to the predefined value to be returned by thewith in case all checked patterns match:{:ok, conf}.

  # Before refactoring:defmodulePhoenix.LiveView.ChanneldouseGenServer...@impltruedefhandle_call({@prefix,:fetch_upload_config,name,cid},_from,state)doread_socket(state,cid,fnsocket,_->result=with{:ok,uploads}<-Map.fetch(socket.assigns,:uploads),{:ok,conf}<-Map.fetch(uploads,name)do#<- redundant last clause!{:ok,conf}#<- predefined value to be returned by the ``with``!end{:reply,result,state}end)end...end

  As demonstrated in the following code, we can refactor this by removing the redundant last clause{:ok, conf} <- Map.fetch(uploads, name) and also replacing the predefined value to be returned with the expressionMap.fetch(uploads, name), which was previously checked in the removed redundant clause.

  # After refactoring:defmodulePhoenix.LiveView.ChanneldouseGenServer...@impltruedefhandle_call({@prefix,:fetch_upload_config,name,cid},_from,state)doread_socket(state,cid,fnsocket,_->result=with{:ok,uploads}<-Map.fetch(socket.assigns,:uploads)doMap.fetch(uploads,name)#<- predefined value to be returned by the ``with``!end{:reply,result,state}end)end...end

  This example is based on an original code refactored by ByeongUk Choi. Source:link

• Side-conditions:

  • The pattern checked in the last clause of thewith statement must be lexically identical to the value returned in the body of thewith. Additionally, the body of thewith should contain only the value to be returned.

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Mining Software Repositories (MSR) study.

• Motivation: All the functions in theEnum module areeager. This means that when performing multiple operations withEnum, each operation will generate an intermediate collection (e.g.,lists ormaps) until we reach the result. On the other hand, Elixir provides theStream module which supportslazy operations, so instead of generating intermediate collections, streams build a series of computations that are invoked only when we pass the underlyingStream to theEnum module. This refactoring suggests using theStream module instead of theEnum modulewhen multiple operations in large collections are performed together. This can significantly decrease the time to traverse the collections while keeping the same behavior.

• Examples: The code examples below illustrate this refactoring. Before the refactoring, the higher-order functionsum_odd_numbers/2 uses onlyEnum's functions to initially modify the values of alist, filter all modified values that are odd, and then sum them up.

  # Before refactoring:defmoduleFoododefsum_odd_numbers(list,odd?)dolist|>Enum.map(&(&1*3))|>Enum.filter(odd?)|>Enum.sum()endend#...Use examples...iex(1)>Foo.sum_odd_numbers([1,2,3,4,5,6,7,8],&(rem(&1,2)!=0))48

  Following the refactoring,sum_odd_numbers/2 retains the same behavior but now uses someStream functions instead ofEnum. Note that even after the refactoring, theEnum.sum/1 function, which is the last operation in the pipeline, was kept in the code. SinceStream module functions arelazy operations, the computations accumulated inStream.map/2 andStream.filter/2 are only invoked when thisStream is passed to a function from theEnum module, in this case theEnum.sum/1 function.

  # After refactoring:defmoduleFoododefsum_odd_numbers(list,odd?)dolist|>Stream.map(&(&1*3))#<- Replace "Enum" with "Stream"!|>Stream.filter(odd?)#<- Replace "Enum" with "Stream"!|>Enum.sum()endend#...Use examples...iex(1)>Foo.sum_odd_numbers([1,2,3,4,5,6,7,8],&(rem(&1,2)!=0))48

  By using theBenchee library for conducting micro benchmarking in Elixir, we can highlight the performance improvement potential of this refactoring. In the following code, thesum_odd_numbers/2 function is given illustrative names,before_ref/1 andafter_ref/1, to represent their respectiveEnum andStream versions.

  list=Enum.to_list(1..50_000_000)odd?=fnx->rem(x,2)!=0endBenchee.run(%{"enum"=>fn->Foo.before_ref(list,odd?)end,"stream"=>fn->Foo.after_ref(list,odd?)end},parallel:4,memory_time:2)

  Note that for a list with fifty million elements, theStream version, although it consumes more memory, can be abouttwelve times faster than theEnum version.

  Operating System: WindowsCPU Information: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHzNumber of Available Cores: 8Available memory: 11.95 GBElixir 1.16.0Erlang 26.2.1Benchmark suite executing with the following configuration:warmup: 2 stime: 5 smemory time: 2 sreduction time: 0 nsparallel: 4inputs: none specifiedEstimated total run time: 18 sBenchmarking enum ...Benchmarking stream ...Name             ips        average  deviation         median         99th %stream         0.144      0.116 min     ±1.63%      0.116 min      0.117 minenum          0.0123       1.36 min    ±49.35%       1.11 min       2.31 minComparison:stream         0.144enum          0.0123 - 11.76x slower +1.24 minMemory usage statistics:Name      Memory usagestream         2.05 GBenum           1.12 GB - 0.55x memory usage -0.93132 GB

  These examples are based on code written in Elixir's official documentation. Source:link

• Side-conditions:

  • Function calls from theEnum module used in a pipeline can only be replaced by functions from theStream module that perform operations equivalent to the originals;

  • To maintain the behavior of the original code, after the calls to functions from theStream module inserted in this refactoring, there must be at least one call to a function from theEnum module in the pipeline.

▲ back to Index

• Category: Elixir-specific Refactorings.

• Source: This refactoring emerged from a Mining Software Repositories (MSR) study.

• Motivation: Elixir provides different types of process abstractions for distinct purposes. While theTask andAgent abstractions have very specific purposes,GenServer is a more generic process abstraction, therefore having the capability to do everything thatTask andAgent can do, as well as having additional capabilities beyond these two specific abstractions. This refactoring aims to transformTask orAgent abstractions intoGenServer when these specific-purpose abstractions are used beyond their suggested purposes. More specifically, this refactoring can be used to remove the code smellGenServer Envy. By using an appropriate process abstraction for the purpose of the code, we can even improve its readability.

• Examples: In the following code, theDatabaseServer module makes use of aTask abstraction to provide its clients with the ability to query a database using the interface functionget/2. As can be observed in this example, thisTaskbehaves like a long-running server process, frequently communicating with other client processes. This behavior is very different from the suggested purpose forTasks, which typically should only perform a particular operation during their lifetime and then stop upon the completion of that operation without communication with other processes.

  # Before refactoring:defmoduleDatabaseServerdouseTaskdefstart_link()doTask.start_link(&loop/0)enddefploop()doreceivedo{:run_query,caller,query_def}->send(caller,{:query_result,run_query(query_def)})endloop()enddefget(server_pid,query_def)dosend(server_pid,{:run_query,self(),query_def})receivedo{:query_result,result}->resultendenddefprun_query(query_def)doProcess.sleep(1000)"#{query_def} result"endend#...Use examples...iex(1)>{:ok,pid}=DatabaseServer.start_link(){:ok,#PID<0.161.0>}iex(2)>DatabaseServer.get(pid,"query 1")"query1result"iex(3)> DatabaseServer.get(pid, "query2") "query2 result"

  Considering that the above code represents an instance of the code smellGenServer Envy, we can refactor it by generalizing the process abstraction used. In other words, we can transform this specific process abstraction (Task) into a generic process abstraction (GenServer). Note that although the process abstraction used has been replaced, the behavior of the code remains the same because the interfaces of the public functions have not been modified. Furthermore, the readability of the refactored code has improved, as it was no longer necessary to make explicit message passing and implement recursive functions to keep the process alive.

  # After refactoring:defmoduleDatabaseServerdouseGenServerdefstart_link()doGenServer.start_link(__MODULE__,nil)enddefget(server_pid,query_def)doGenServer.call(server_pid,{:run_query,query_def})enddefprun_query(query_def)doProcess.sleep(1000)"#{query_def} result"end@impldefhandle_call({:run_query,query_def},_,state)do{:reply,run_query(query_def),state}endend#...Use examples...iex(1)>{:ok,pid}=DatabaseServer.start_link(){:ok,#PID<0.164.0>}iex(2)>DatabaseServer.get(pid,"query 1")"query1result"iex(3)> DatabaseServer.get(pid, "query2") "query2 result"

  This example is based on an original code by Saša Jurić available in the"Elixir in Action, 2. ed." book.

▲ back to Index

Traditional refactorings are those mainly based on Fowler's catalog or that use programming features independent of languages or paradigms. In this section, 25 different refactorings classified as traditional are explained and exemplified:

• Category: Traditional Refactorings.

• Motivation: It's important to keep in mind that although giving good names to things may not be a simple task, good names for code structures are essential to facilitate maintenance activities promoted by humans. When the name of an identifier does not clearly convey its purpose, it should be renamed to improve the code's readability, thus avoiding a developer from wasting too much time trying to understand code developed by someone else or even developed by themselves a long time ago. In Elixir, code identifiers can befunctions,modules,macros,variables,map/struct fields, registered processes (e.g.GenServer),protocols,behaviours callbacks,module aliases,module attributes,function parameters, etc.

• Examples: The following code illustrates this refactoring in the context ofrenaming functions. Before the refactoring, we have a functionfoo/2, which receives two parameters and returns their sum. Although it is a simple function, it is evident that its name does not clearly convey its purpose.

  # Before refactoring:deffoo(value_1,value_2)dovalue_1+value_2end

  We intend to rename this function tosum/2, thus highlighting its purpose. To do so, we should create a new function with this name and copy the body of thefoo/2 function to it. Additionally, the body of thefoo/2 function should be replaced by a call to the newsum/2 function:

  # After refactoring:defsum(value_1,value_2)dovalue_1+value_2enddeffoo(value_1,value_2)do#<-- must be deleted in the future!sum(value_1,value_2)end

  Thefoo/2 function acts as a wrapper that callssum/2 and should be kept in the code temporarily, only while the calls to it throughout the codebase are gradually replaced by calls to the newsum/2 function. This mitigates the risk of this refactoring generating breaking changes. When there are no more calls to thefoo/2, it should be deleted from its module.

• Side-conditions:

  • The new name should not conflict with other pre-existing names;

  • In the specific case ofrenaming functions, the new function name should not conflict with other functions of the same module, nor with those imported from another module.

• Mechanics: This sequence of steps may vary depending on the type of identifier that will be renamed. In the specific case ofrenaming functions, the sequence of steps for the transformation should be as follows.

  • Check if the function being renamed was not previously defined by an Elixirbehaviour orprotocol implemented by the module of the function;

    • If the name was originally defined in abehaviour orprotocol, these transformations should be promoted at the source of that function (behaviour orprotocol) and in all modules of the codebase that implement that source.

  • Create a new function with a name that better indicates its purpose and copy the body of the original function (with a bad name) into the new function;

  • Replace the body of the original function with a call to the new function;

  • Test your code to check for the occurrence of breaking changes;

  • For each call to the original function, replace it with a call to the new renamed function and test your code again;

  • After all calls to the original function have been replaced with the new function, and the code has been tested to verify that there are no breaking changes, it is safe to delete the original function and its definitions in abehaviour orprotocol (if applicable) to complete the refactoring process.

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: Modules in Elixir are used to group related and interdependent definitions, promoting cohesion. A definition in Elixir can be afunction,macro, orstruct, for example. When a definition accesses more data or calls more functions from another module other than its own, or is used more frequently by another module, we may have less cohesive modules with high coupling. To improve maintainability by grouping more cohesive definitions in modules, these definitions should be moved between modules when identified. This refactoring helps to eliminate theFeature Envy code smell.

• Examples: The following code illustrates this refactoring in the context ofmoving functions. Before the refactoring, we have a functionfoo/2 fromModuleA, which besides not being called by any other function in its module, only makes calls to functions from another module (ModuleB). This functionfoo/2, as it is clearly misplaced inModuleA, decreases the cohesion of this module and creates an avoidable coupling withModuleB, making the codebase harder to maintain.

  # Before refactoring:defmoduleModuleAdoaliasModuleB,as:Bdeffoo(v1,v2)doB.baz(v1,v2)|>B.qux()enddefbar(v1)do...endend#...Use example...iex(1)>ModuleA.foo(1,2)

  # Before refactoring:defmoduleModuleBdodefbaz(value_1,value_2)do...enddefqux(value_1)do...endend

  We want to movefoo/2 toModuleB to improve the grouping of related functions in our codebase. To do this, we should not only copyfoo/2 toModuleB, but also check iffoo/2 depends on other resources that should also be moved or if it has references that need to be updated when the function is positioned in its new module.

  # After refactoring:defmoduleModuleAdodefbar(v1)do...endend

  # After refactoring:defmoduleModuleBdodefbaz(value_1,value_2)do...enddefqux(value_1)do...enddeffoo(v1,v2)do#<-- moved function!baz(v1,v2)|>qux()endend#...Use example...iex(1)>ModuleB.foo(1,2)

  All calls toModuleA.foo/2 should be updated toModuleB.foo/2. When there are no more calls toModuleA.foo/2 in the codebase, it should be deleted fromModuleA. In addition,ModuleA will no longer need to import functions fromModuleB, since this coupling has been undone.

• Side-conditions:

  • When the moved definition is afunction ormacro, the name of this definition must not conflict with the name of any other definition of the same type already defined in the target module or imported by it;

  • When the moved definition is afunction that originally calls other functions or macros, after the refactoring, this moved function must still refer to the same definitions of functions and macros originally called;

  • When the moved definition is astruct, it can only be moved to a target module that does not already define anotherstruct.

  These side conditions are based on definitions written by László Löveiet al. in this paper:[1]

▲ back to Index

• Category: Traditional Refactorings.

• Motivation: This refactoring is used when it is necessary to request additional information from the callers of a function or the opposite situation, when some information passed by the callers is no longer necessary. The transformation promoted by this refactoring usually creates a new function with the same name as the original, but with a new parameter added or a parameter removed, and the body of the original function is replaced by a call to the new function, subsequently replacing the calls to the original function with calls to the new function. Thanks to the possibility of specifying default values for function parameters in Elixir, using the\\ operator, we can simplify the mechanics of this refactoring, as shown in the following example.

• Examples: The following code has afoo/1 function that always sum the constant +1 to thevalue passed as a parameter.

  # Before refactoring:deffoo(value)dovalue+1end

  We want to add a parameter to the functionfoo/1 to generalize the constant used in the sum. To do this, we can addnew_arg at the end of the parameter list, accompanied by the default value\\ 1. In addition, we should modify the body of the function to use this new parameter, as shown below.

  # After refactoring:deffoo(value,new_arg\\1)dovalue+new_argend

  Note that although we have now only explicitly implemented thefoo/2 function, in Elixir this definition generates two functions with the same name, but with different arities:foo/1 andfoo/2. This will allow the callers of the original function to continue functioning without any changes. Although the example has only emphasized the addition of new parameters using default values, this feature can also be useful when we want to remove a parameter from a function, decreasing its arity. We can define a default value for the parameter to be removed when it is no longer used in the body of the function. This will keep the higher arity function callers working, even if providing an unused additional value. Additionally, new callers of the lower arity function can coexist in the codebase. When all old callers of the higher arity function are replaced by calls to the lower arity function, the parameter with the default value can finally be removed from the function without compromising any caller.

• Side-conditions:

  • When adding a new parameter, its name (e.g.,new_arg) must not conflict with the name of any other parameter or local variable in the refactored function;

  • When adding a new parameter to a function and thus increasing its arity, this operation must not conflict with functions of the same name and arity that are already defined or imported into the refactored module;

  • When removing a parameter, it should not be used in the definition of the function that is being refactored;

  • When removing a parameter from a function and thus reducing its arity, this operation must not conflict with functions of the same name and arity that are already defined or imported into the refactored module.

  These side conditions are based on definitions provided by members of the HaRe project (Haskell Refactorer tool), as described in the following link:[1]

▲ back to Index

• Category: Traditional Refactorings.

• Motivation: This refactoring can be useful to eliminate theLong Parameter List code smell. When functions have very long parameter lists, their interfaces can become confusing, making the code difficult to read and increasing the propensity for bugs. This refactoring concentrates on grouping a number of a function's sequential and related parameters into atuple, thereby shortening the list of parameters. The function`s callers are also modified by this refactoring to correspond to the new parameter list.Tuple is a data type supported by Elixir and is often used to group a fixed number of elements.

• Examples: The following code presents theFoo module, composed only by therand/2 function. This function takes two values as a parameter and returns the random number present in the range defined by the two parameters. Althoughrand/2's parameter list is not necessarily long, try to imagine a scenario where a function has a list consisting of five or more parameters, for example. Furthermore, not always all parameters of a function can be grouped as in this example.

  # Before refactoring:defmoduleFoododefrand(first,last)doEnum.random(first..last)endend#...Use examples...iex(1)>Foo.rand(1,9)4iex(2)>Foo.rand(2,8)2

  We want to find and group parameters that are related, thus decreasing the size of the list. Note that in this case, the two parameters in the list form an interval, so they are related and can be grouped to compose the functionrand/1, as shown below.

  # After refactoring:defmoduleFoododefrand({first,last}=group)doEnum.random(first..last)endend#...Use examples...iex(1)>g={1,9}#<= tuple definitioniex(2)>Foo.rand(g)5iex(3)>g={2,8}#<= tuple definitioniex(4)>Foo.rand(g)7iex(5)>g={2,8,3}#<= wrong tuple definition!iex(6)>Foo.rand(g)**(FunctionClauseError) no function clause matchinginFoo.rand/1

  The functionrand/1 performs pattern matching with the value of its single parameter. This, in addition to allowing the extraction of the values that make up thetuple, allows for validating whether the format of the parameter received in the call is really that of thetuple of the expected length. Also, note that this refactoring updates all function callers to the new parameter list.

  Important: Although this refactoring has grouped parameters usingtuples, we can find in different functions identical groups of parameters that could be grouped (i.e., Data Clumps). In that case, is better to create astruct to group these parameters and reuse thisstruct to refactor all functions where this group of parameters occurs.

• Side-conditions:

  • The grouped parameters must be sequential in the original parameter list of the modified function;

  • The function created by this refactoring, with reduced arity, must not conflict with any existing functions defined in the same module or imported by it;

  • The refactored function must not be an OTP callback function (e.g.,GenServer.handle_call/3).

  These side conditions are based on definitions written by Huiqing Liet al. in this paper:[1]

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: Although the order of parameters does not change the complexity of executing a code for the machine, when a function has parameters defined in an order that does not group similar semantic concepts, the code can become more confusing for programmers, making it difficult to read and also becoming more prone to errors during its use. When we find functions with poorly organized parameters, we must reorder them in a way that allows for better readability and meaning for programmers.

• Examples: The following code illustrates this refactoring. Before the refactoring, we have a functionarea/3, responsible for calculating the area of a trapezoid. Although the body of this function is correct, the two bases of the trapezoid are not sequential parameters, so this can confuse a programmer when this function is called. The area of a trapezoid that hasmajor_base = 24 cm,minor_base = 9 cm, andheight = 15 cm equals 247.5 cm^2. In the first call ofarea/3 in the example, the programmer imagined that the values of the bases would be the first two parameters of the function and thus had a calculation error that could easily go unnoticed.

  # Before refactoring:defarea(major_base,height,minor_base)do((major_base+minor_base)*height)/2end#...Use examples...iex(1)>Trapezoid.area(24,9,15)#<- misuse175.5iex(2)>Trapezoid.area(24,15,9)247.5

  We want to reorder the parameters ofarea/3 to make them semantically organized. To do so, we should create a new functionnew_area/3, which will have the parameters reordered and copy the body of thearea/3 to it. Additionally, the body of thearea/3 should be replaced by a call to thenew_area/3:

  # After refactoring:defnew_area(major_base,minor_base,height)do#<-- can be renamed in the future!((major_base+minor_base)*height)/2enddefarea(major_base,height,minor_base)do#<-- must be deleted in the future!new_area(major_base,minor_base,height)end#...Use examples...iex(1)>Trapezoid.new_area(24,9,15)247.5iex(2)>Trapezoid.area(24,15,9)247.5

• Side-conditions:

  • The new function created by this refactoring must have the same arity as the original function and have a name different from all others defined or imported by the refactored module, avoiding conflicts;
  • Immediately after the refactoring, there should be no calls to the newly created function (e.g.,new_area/3) anywhere other than within the body of the original function (e.g.,area/3).

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: For us to have code with easy readability, it is important that its purpose be clearly exposed, not requiring a developer to spend too much time to understand its purpose. Sometimes we come across functions that concentrate on many purposes and therefore become long (Long Functions), making their maintenance difficult. It is common in such functions to find code comments used to explain the purpose of a sequence of lines. Whenever we encounter functions with these characteristics, we should extract these code sequences into a new function that has a name that clearly explains its purpose. In the original function, the extracted code block should be replaced by a call to the new function. This refactoring makes functions smaller and more readable, thus facilitating their maintenance.

• Examples: The following code illustrates this refactoring. Before the refactoring, we have a functionticket_booking/5, responsible for booking an airline ticket for a passenger. All the main steps of the booking are done through a sequence of operations chained by pipe operators. After payment confirmation, the booking process is finalized by returning a tuple containing important reservation data that must be informed to the passenger. We can observe that the last 3 lines of theticket_booking/5 function are responsible for presenting a report. Note that these lines were preceded by a comment attempting to explain their purposes, highlighting that these expressions are misplaced withinticket_booking/5 and even require documentation to help understand the code.

  # Before refactoring:defticket_booking(passenger,air_line,date,credit_card,seat)do{company,contact_info,cancel_policy}=check_availability(air_line,date)|>documents_validation(passenger)|>select_seat(seat)|>payment(credit_card)#print booking reportIO.puts("Booking made at the company:#{company}")IO.puts("Any doubt, contact:#{contact_info}")IO.puts("For cancellations, see company policies:#{cancel_policy}")end

  We want to make this code more concise, reducing the size ofticket_booking/5 and improving its readability. To achieve this, we should create a new functionreport/1 that will receive a tuple as a parameter, extract the values from the tuple to variables via pattern matching, and finally present the report containing these values. In addition, the body ofticket_booking/5 should be updated to include a call toreport/1 to replace the extracted lines of code.

  # After refactoring:defreport({company,contact_info,cancel_policy}=confirmation)doIO.puts("Booking made at the company:#{company}")IO.puts("Any doubt, contact:#{contact_info}")IO.puts("For cancellations, see company policies:#{cancel_policy}")enddefticket_booking(passenger,air_line,date,credit_card,seat)docheck_availability(air_line,date)|>documents_validation(passenger)|>select_seat(seat)|>payment(credit_card)|>report()#<- extracted function call!end

  This refactoring not only improves the readability ofticket_booking/5, but also enables more code reuse, sincereport/1 may eventually be called by other functions in the codebase.

• Side-conditions:

  • The name and arity of extracted function created in this refactoring (e.g.,report/1) must not conflict with the name of any other function already defined or imported by the refactored module;

  • The extracted sequence of expressions must not make recursive calls to the original function;

  • The extracted sequence of expressions must not be originally included in aguard sequence;

  • The extracted sequence of expressions must not be originally part of a pattern;

  • The extracted sequence of expressions must not be originally within amacro definition.

  These side conditions are based on definitions provided by members of the RefactorErl project, as described in the following link:[1]

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: This refactoring is the inverse ofExtract Function. We typically extract functions to reduce their size, making them more readable and easier to maintain. However, in some situations, the body of a function basically just delegates to the call of another function. In these cases, the purpose of the function body is as clear as its name, and there is no benefit in keeping the declaration of this function. In fact, excessive delegation may create code with very indirect execution flows that are difficult to debug. In these situations, an inline function can be used, replacing all calls to the function with its body, and then getting rid of the function.

• Examples: The following code illustrates this refactoring. Before the refactoring, we have a module calledOrder composed of the private functionsum_list/1 and the public functionget_amount/1. The functionget_amount/1 receives a list of items in an order and delegates the sum of all item values to thesum_list/1 function. As we can see, thesum_list/1 function simply calls theEnum.sum/1 function provided natively by Elixir, thus being an example of excessive and unnecessary delegation.

  # Before refactoring:defmoduleOrderdodefpsum_list(list)doEnum.sum(list)enddefget_amount(order_itens)dosum_list(order_itens)endend

  To eliminate the excessive delegation generated by thesum_list/1 function, we will replace all calls tosum_list/1 with its body. Then, we can delete thesum_list/1 function from theOrder module since it will no longer be necessary.

  # After refactoring:defmoduleOrderdodefget_amount(order_itens)doEnum.sum(order_itens)#<- inlined function!endend

  This refactoring preserves the behavior of the function and will make it easier for the programmer to debug the code.

• Side-conditions:

  • The body of the original function, which is used to replace its calls, must not contain variables that conflict with the names of other variables already existing in the scope where the function calls occurred;

  • If the calls replaced by the body of a function refer to a function defined in a different module, the body of that function must not contain calls to functions that are not imported in the scope where the replaced calls occurred.

  These side conditions are based on definitions provided by members of the RefactorErl project, as described in the following link:[1]

▲ back to Index

• Category: Traditional Refactorings.

• Motivation: This refactoring can be used in the context of removingDuplicated Code, replacing a set of expressions with a call to an existing function that performs the same processing as the duplicated code. The opportunity to apply this refactoring may occur after the chained execution of theExtract function andGeneralise a function definition refactorings. After generalizing a function that has been previously extracted, it is possible that there may still be some code snippets in the codebase that are duplicated with the generalized function. This refactoring aims to, from a source function, find code that is duplicated in relation to it and replace the duplications with calls to the source function. Some adaptations in these new call points to the source function may be necessary to preserve the code's behavior.

• Examples: The following code exemplifies this refactoring. Before the refactoring, we have aClass module composed of two functions. The functionreport/1 was previously extracted from a code snippet not shown in this example. Later, this extracted function was generalized, resulting in its current format. The functionimprove_grades/3 already existed in theClass module beforereport/1 was generated through refactoring. Note thatimprove_grades/3 has code snippets that are duplicated withreport/1.

  # Before refactoring:defmoduleClassdodefstruct[:id,:grades,:avg,:worst,:best]defreport(list)do#<- Generated after extraction and generalisation!avg=Enum.sum(list)/length(list){min,max}=Enum.min_max(list){avg,min,max}enddefimprove_grades(class_id,grades,students_amount)dohigh_grade=Enum.max(grades)adjustment_factor=100/high_gradenew_grades=Enum.map(grades,&(&1*adjustment_factor)|>Float.round(2))grades_avg=Enum.sum(new_grades)/students_amount#<- duplicated code{w,b}=Enum.min_max(new_grades)#<- duplicated code%Class{id:class_id,grades:new_grades,avg:grades_avg,worst:w,best:b}endend#...Use examples...iex(1)>Class.improve_grades(:software_engineering,[26,49,70,85,20,75,74,15],8)%Class{id::software_engineering,grades:[30.59,57.65,82.35,100.0,23.53,88.24,87.06,17.65],avg:60.88375,worst:17.65,best:100.0}

  We want to eliminate the duplicated code inimprove_grades/3. To achieve this, we can replace the duplicated code snippet with a call toreport/1. Note that some adaptations to the function call that will replace the duplicated code may be necessary.

  # After refactoring:defmoduleClassdodefstruct[:id,:grades,:avg,:worst,:best]defreport(list)doavg=Enum.sum(list)/length(list){min,max}=Enum.min_max(list){avg,min,max}enddefimprove_grades(class_id,grades,students_amount)dohigh_grade=Enum.max(grades)adjustment_factor=100/high_gradenew_grades=Enum.map(grades,&(&1*adjustment_factor)|>Float.round(2)){grades_avg,w,b}=report(new_grades)#<- Folding against a function definition!%Class{id:class_id,grades:new_grades,avg:grades_avg,worst:w,best:b}endend#...Use examples...iex(1)>Class.improve_grades(:software_engineering,[26,49,70,85,20,75,74,15],8)%Class{id::software_engineering,grades:[30.59,57.65,82.35,100.0,23.53,88.24,87.06,17.65],avg:60.88375,worst:17.65,best:100.0}

  Also note that in this example, after the refactoring is done, the third parameter of theimprove_grades/3 function is no longer used in the function body. This is an opportunity to apply theAdd or remove parameter refactoring.

• Side-conditions:

  • The duplicated code to be replaced and the function to be called to perform this refactoring must be defined in the same module;

  • After replacing the duplicated code with a function call, compensations (e.g., pattern matching to extract values returned by the function) may be necessary to maintain the code's original behavior.

  These side conditions are based on definitions provided by members of the HaRe project (Haskell Refactorer tool), as described in the following link:[1]

▲ back to Index

• Category: Traditional Refactorings.

• Motivation: This refactoring aims to improve code readability and maintainability. When we use meaningless numbers (magic numbers) directly in expressions, code comprehension can become more complex for humans. Additionally, if the same meaningless number is scattered throughout the codebase and needs to be modified in the future, it can generate a significant maintenance burden, increasing the risk of bugs. To improve the code, this refactoring seeks to create a constant with a meaningful name for humans and replace occurrences of the meaningless number with the extracted constant.

• Examples: The following code provides an example of this refactoring. Prior to the refactoring, we had aCircle module consisting of two functions. Both functions used the magic number3.14. Although this example contains simple code that may not seem to justify the developer's concern with extracting constants, try to imagine a more complex scenario involving larger and non-trivial code that makes more extensive use of these meaningless numbers. This could cause a lot of headache for a developer.

  # Before refactoring:defmoduleCircledodefarea(r)do3.14*r**2enddefcircumference(r)do2*3.14*rendend#...Use examples...iex(1)>Circle.area(3)28.26iex(2)>Circle.circumference(3)18.84

  To improve the comprehension of this code and make it easier to maintain, we can create amodule attribute with a human-readable name (@pi) and replace the numbers with the use of this attribute.

  # After refactoring:defmoduleCircledo@pi3.14#<- extracted constant!defarea(r)do@pi*r**2enddefcircumference(r)do2*@pi*rendend#...Use examples...iex(1)>Circle.area(3)28.26iex(2)>Circle.circumference(3)18.84

  This not only gives meaning to the number but also facilitates maintenance in case it needs to be changed. In the case of@pi, if we wish to improve the precision of the calculations by adding more decimal places to its value, this can be easily done in the refactored code.

▲ back to Index

• Category: Traditional Refactorings.

• Motivation: This is a refactoring motivated by the compiler optimization technique known as copy propagation. Copy propagation is a transformation that, for an assignment of the forma =b, replaces uses of the variablea with the value of the variableb, thus eliminating redundant computations. This refactoring can be very useful for eliminating temporary variables that are responsible only for storing results to be returned by a function, or even intermediate values used during processing.

• Examples: The following code provides an example of this refactoring. Prior to the refactoring, we have a functionbar/2 that takes an integer valueb and alist as parameters. The function returns a tuple containing two elements, the first of which is the value contained in the indexc of thelist and the second of which is the sum of all elements in a modified version of thelist.

  # Before refactoring:defmoduleFoododefbar(b,list)whenis_integer(b)doa=b*2c=aresult_1=Enum.at(list,c)r=aresult_2=Enum.map(list,&(&1+r))|>Enum.sum(){result_1,result_2}endend#...Use examples...iex(1)>Foo.bar(2,[1,2,3,4,5,6]){5,45}

  To perform this processing, the code above makes excessive and unnecessary use of temporary variables. As shown below, after the refactoring, these temporary variables will be replaced by their values and subsequently removed when they are no longer used in any location.

  # After refactoring:defmoduleFoododefbar(b,list)whenis_integer(b)do{Enum.at(list,b*2),Enum.map(list,&(&1+b*2))|>Enum.sum()}endend#...Use examples...iex(1)>Foo.bar(2,[1,2,3,4,5,6]){5,45}

  This refactoring can promote a significant simplification of some code, as well as avoid redundant computations that can harm performance.

• Side-conditions:

  • The variable has only one binding occurrence on the left-hand side of a pattern matching expression and is not part of a compound pattern;

  • The expression bound to the variable is pure, meaning it has no side effects.

  These side conditions are based on definitions provided by members of the RefactorErl project, as described in the following link:[1]

▲ back to Index

• Category: Traditional Refactorings.

• Note: Formerly known as "Merge expressions".

• Motivation: This refactoring, in a way, behaves as the inverse ofTemporary variable elimination. When programming, we may sometimes come across unavoidably large and hard-to-understand expressions. With this refactoring, we can break down those expressions into smaller parts and assign them to local variables with meaningful names, thus facilitating the overall understanding of the code. In addition, this refactoring can help eliminateDuplicated Code, as the variables extracted from the expressions can be reused in various parts of the codebase, avoiding the need for repetition of long expressions.

• Examples: The following code provides an example of this refactoring. Prior to the refactoring, we have a moduleBhaskara composed of the functionsolve/3, responsible for finding the roots of a quadratic equation. This function returns a tuple with the roots or their non-existence.

  # Before refactoring:defmoduleBhaskaradodefsolve(a,b,c)doifb*b-4*a*c<0do{:error,"No real roots"}elsex1=(-b+(b*b-4*a*c)**0.5)/(2*a)x2=(-b-(b*b-4*a*c)**0.5)/(2*a){:ok,{x1,x2}}endendend#...Use examples...iex(1)>Bhaskara.solve(1,3,-4){:ok,{1.0,-4.0}}iex(2)>Bhaskara.solve(1,2,1){:ok,{-1.0,-1.0}}iex(3)>Bhaskara.solve(1,2,3){:error,"No real roots"}

  Note that in this function, besides the expressionb*b - 4*a*c being repeated several times, including within a larger expression, the lack of meaning forb*b - 4*a*c can make the code less readable. We can solve this by extracting a new variabledelta, assigningb*b - 4*a*c to this new variable, and replacing all instances of this expression with the use of thedelta variable.

  # After refactoring:defmoduleBhaskaradodefsolve(a,b,c)dodelta=(b*b-4*a*c)#<- extracted variable!ifdelta<0do{:error,"No real roots"}elsex1=(-b+delta**0.5)/(2*a)x2=(-b-delta**0.5)/(2*a){:ok,{x1,x2}}endendend#...Use examples...iex(1)>Bhaskara.solve(1,3,-4){:ok,{1.0,-4.0}}iex(2)>Bhaskara.solve(1,2,1){:ok,{-1.0,-1.0}}iex(3)>Bhaskara.solve(1,2,3){:error,"No real roots"}

• Side-conditions:

  • The name of the new variable created in this refactoring (e.g.,delta) must not conflict with the name of any other variable already defined in the same scope;

  • The expression to be extracted into a variable must originally be contained within the body of a function and not be part of a guard expression;

  • The expression cannot be replaced by a variable if any of its sub-expressions are not pure, meaning they have side effects.

  These side conditions are based on definitions provided by members of the RefactorErl project, as described in the following link:[1]

  Recalling previous refactorings: Although the refactored code shown above has made the code more readable, it still has opportunities for applying other refactorings previously documented in this catalog. Note that for the calculation of the roots, we have two lines of code that are practically identical. In addition, we have two temporary variables (x1 andx2) that have only the purpose of storing results that will be returned by the function. If we take this refactored version of the code after applyingExtract expressions and apply a composite refactoring with the sequence ofExtract function ->Generalise a function definition ->Fold against a function definition ->Temporary variable elimination, we can arrive at the following version of the code:

  # After a composite refactoring:defmoduleBhaskaradodefproot(a,b,delta,operation)dooperation.(-b,delta**0.5)/(2*a)enddefsolve(a,b,c)dodelta=(b*b-4*a*c)ifdelta<0do{:error,"No real roots"}else{:ok,{root(a,b,delta,&Kernel.+/2),root(a,b,delta,&Kernel.-/2)}}endendend#...Use examples...iex(1)>Bhaskara.solve(1,3,-4){:ok,{1.0,-4.0}}iex(2)>Bhaskara.solve(1,2,1){:ok,{-1.0,-1.0}}iex(3)>Bhaskara.solve(1,2,3){:error,"No real roots"}

▲ back to Index

• Category: Traditional Refactorings.

• Motivation: This refactoring can be used as a solution for removing the code smellLarge Module, also known as Large Class in object-oriented languages. When a module in Elixir code does the work of two or more, it becomes large, poorly cohesive, and difficult to maintain. In these cases, we should split this module into several new ones, moving to each new module only the attributes and functions with purposes related to their respective goals.

• Examples: The code example below demonstrates the application of this refactoring technique. In this case, theShoppingCart module is excessively large and lacks cohesion, as it combines functions related to at least four distinct and unrelated business rules.

  # Before refactoring:defmoduleShoppingCartdo# Rule 1defcalculate_total(items,subscription)do# ...end# Rule 1defcalculate_shipping(zip_code,%{id:3}),do:0.0defcalculate_shipping(zip_code,%{id:4}),do:0.0defcalculate_shipping(zip_code,_),do10.0*Location.calculate(zip_code)end# Rule 2defapply_discount(total,%{id:3}),do:total*0.9defapply_discount(total,%{id:4}),do:total*0.9defapply_discount(total,_),do:total# Rule 3defsend_message_subscription(%{id:3},_),do:nildefsend_message_subscription(%{id:4},_),do:nildefsend_message_subscription(subscription,user),do:# something# Rule 4defreport(user,order)do# ...endend

  Applying this refactoring three times,ShoppingCart can be splitted, and some of its functions could be moved to other new modules (Item,Subscription, andUtil), thus increasing the codebase overall cohesion.

  # After refactoring:defmoduleShoppingCartdo# Rule 1defcalculate_total(items,subscription)do# ...end# Rule 1defcalculate_shipping(zip_code,%{id:3}),do:0.0defcalculate_shipping(zip_code,%{id:4}),do:0.0defcalculate_shipping(zip_code,_),do10.0*Location.calculate(zip_code)endend

  # After refactoring:defmoduleItemdo# Rule 2defapply_discount(total,%{id:3}),do:total*0.9defapply_discount(total,%{id:4}),do:total*0.9defapply_discount(total,_),do:totalend

  # After refactoring:defmoduleSubscriptiondo# Rule 3defsend_message_subscription(%{id:3},_),do:nildefsend_message_subscription(%{id:4},_),do:nildefsend_message_subscription(subscription,user),do:# somethingend

  # After refactoring:defmoduleUtildo# Rule 4defreport(user,order)do# ...endend

  Each application of this refactoring involves creating a new module, selecting the set of definitions that should be moved to that new module, and applying theMoving a definition refactoring to each of those selected definitions. Any reference and dependency issues inherent in moving functions between modules are compensated for by theMoving a definition refactoring. Although this does not happen in the above example, in some cases, after splitting an original module into several smaller and more cohesive modules, the name of the original module can no longer makes sense, providing an opportunity to also apply theRename an identifier refactoring.

▲ back to Index

• Category: Traditional Refactoring.

• Note: Formerly known as "Simplifying nested conditional statements".

• Motivation: Sometimes nested conditional statements can unnecessarily decrease the readability of the code. This refactoring aims to simplify the code by eliminating unnecessary nested conditional statements.

• Examples: The following code shows an example of this refactoring. Before the refactoring, we have the functionsconvert/2 andqux/3. The private functionconvert/2 takes alist and a boolean valueswitch as parameters. Ifswitch is true, thelist is converted to a tuple; otherwise, thelist is not modified. The public functionqux/3 takes alist, avalue, and anindex as parameters and then calls theconvert/2 function. If thelist contains thevalue at theindex,qux/3 calls theconvert/2 function with the second parameter set to true; otherwise, the second parameter is set to false.

  # Before refactoring:defmoduleFoododefpconvert(list,switch)docaseswitchdotrue->{:tuple,List.to_tuple(list)}_->{:list,list}endenddefqux(list,value,index)docaseconvert(list,caseEnum.at(list,index)do^value->true_->falseend)do{:tuple,_}->"Something..."{:list,_}->"Something else..."endendend#...Use examples...iex(1)>Foo.qux([1,7,3,8],7,0)"Something else..."iex(2)>Foo.qux([1,7,3,8],7,1)"Something..."

  Note that the functionqux/3 uses two nestedcase statements to perform its operations, with the innermostcase statement responsible for setting the boolean value of the second parameter in the call toconvert/2. As shown in the following code, we can simplify this code by replacing the innermostcase statement with a strict equality comparison (===).

  # After refactoring:defmoduleFoodo...defqux(list,value,index)docaseconvert(list,Enum.at(list,index)===value)do{:tuple,_}->"Something..."{:list,_}->"Something else..."endendend#...Use examples...iex(1)>Foo.qux([1,7,3,8],7,0)"Something else..."iex(2)>Foo.qux([1,7,3,8],7,1)"Something..."

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: Move a project file between directories, which contains code such as modules, macros, structs, etc. This refactoring can improve the organization of an Elixir project, grouping related files in the same directory, which may, for example, belong to the same architectural layer. This refactoring can also impact the updating of references made by dependents of the code present in the moved file.

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: Dead code (i.e., unused code) can pollute a codebase making it longer and harder to maintain. This refactoring aims to clean the codebase by eliminating code definitions that are not being used.

• Examples: The following code shows an example of this refactoring. Before the refactoring, we have a functionbar/2 that modifies the two values received as parameters and then returns the power of both.

  # Before refactoring:defmoduleFoododefbar(v1,v2)dov1=v1**2v2=v2+5dead_code=v2/2#<= can be removed!{:ok,v1**v2}endend#...Use examples...iex(1)>c("sample.ex")warning:variable"dead_code"isunused...sample.ex:5: Foo.bar/2iex(2)>Foo.bar(2,1){:ok,4096}

  Note that when this code is compiled, Elixir's compiler itself informs the existence of unused code that could be eliminated to clean up the codebase. As shown in the following code, this refactoring eliminated thedead_code inbar/2 without causing any side effects to the function's behavior.

  # After refactoring:defmoduleFoododefbar(v1,v2)dov1=v1**2v2=v2+5{:ok,v1**v2}endend#...Use examples...iex(1)>Foo.bar(2,1){:ok,4096}

• Side-conditions:

  • Considering that the code removed by this refactoring must be either commented out or not referenced by any other part of the codebase, this refactoring can be performed without the need to meet any additional specific conditions.

▲ back to Index

• Category: Traditional Refactoring.

• Note: Formerly known as "Introduce or remove a duplicate definition".

• Motivation: When we want to test a modification in a code without losing its original definition, we can temporarily duplicate it with a new identifier. Once this new version of the code is approved, it will replace the original version and the duplication will be removed.

• Examples: The following code shows an example of this refactoring. Before the refactoring, we have a functionbar/2 that returns the power of their parameters.

  # Before refactoring:defmoduleFoododefbar(v1,v2)dov3=v1**v2{:ok,v3}endend#...Use examples...iex(1)>Foo.bar(5,2){:ok,25}

  Imagine that for some reason it is necessary to change the definition ofv3, but while the new version ofv3 is not approved, we also want to keep the original version in the codebase. The following code shows the application of this refactoring, duplicating the definition ofv3.

  # After refactoring:defmoduleFoododefbar(v1,v2)dov3=v1**v2#<= definition to be changed!v3_duplication=v1**v2#<= original version!{:ok,v3}endend#...Use examples...iex(1)>Foo.bar(5,2){:ok,25}

• Side-conditions:

  • Note that the identifier of the introduced duplicated code (v3_duplication) should not conflict with any other existing identifier in the code;

  • Once the new version of the code has been implemented and approved, the duplication can be removed from the codebase by this refactoring. If the new version is disapproved, we can return to the original version by applyingRename an identifier to it.

  These side conditions are based on definitions provided by members of the HaRe project (Haskell Refactorer tool), as described in the following link:[1]

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: Function overloading enables the creation of variations of an existing function, that is, the definition of two or more functions with identical names but different parameters. In Elixir, this can be done with functions of different arities or with multi-clause functions of the same arity. This refactoring allows for the creation of a variation of a function, enabling its use in different contexts.

• Examples: The following code shows an example of this refactoring. Before the refactoring, we have a functiondiscount/1 that allows applying a 30% discount on orders that cost at least100.0.

  # Before refactoring:defmoduleOrderdodefstruct[date:nil,total:nil]defdiscount(%Order{total:t}=s)whent>=100.0do%Order{s|total:t*0.7}endend#...Use examples...iex(1)>Order.discount(%Order{total:150.0,date:~D[2022-11-10]})%Order{date:~D[2022-11-10],total:105.0}iex(2)>Order.discount(%Order{total:90.0,date:~D[2022-10-18]})**(FunctionClauseError) no function clause matchinginOrder.discount/1

  Consider a scenario where this e-commerce wants to implement new discount rules for new situations or specific dates. This could be done by overloading thediscount/1 function, creating for example a new clause for it that will be applied on purchases made on Christmas day, and also a variationdiscount/2, that could be applied for discounts on exceptional cases. The following code presents these two refactorings of the originaldiscount/1 function.

  # After refactoring:defmoduleOrderdodefstruct[date:nil,total:nil]# newdefdiscount(%Order{date:d,total:t}=s)whend.day==25andd.month==12do%Order{s|total:t*0.1}end# originaldefdiscount(%Order{total:t}=s)whent>=100.0do%Order{s|total:t*0.7}end# newdefdiscount(%Order{total:t}=s,value)do%Order{s|total:t*value}endend#...Use examples...iex(1)>Order.discount(%Order{total:150.0,date:~D[2022-12-25]})%Order{date:~D[2022-12-25],total:15.0}iex(2)>Order.discount(%Order{total:150.0,date:~D[2022-11-10]})%Order{date:~D[2022-11-10],total:105.0}iex(3)>Order.discount(%Order{total:90.0,date:~D[2022-10-18]},0.8)%Order{date:~D[2022-10-18],total:72.0}

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: The use of theimport directive in a module allows calling functions defined in other modules without having to specify them directly in each call. While this can reduce the size of code, the use ofimport can also harm the readability of code, making it difficult to identify directly the source of a function being called. This refactoring allows removing theimport directives in a module, replacing all calls to imported functions with the formatModule.function(args).

• Examples: The following code shows an example of this refactoring.

  # Before refactoring:defmoduleBardodefsum(v1,v2)dov1+v2endenddefmoduleFoodoimportBar#<= to be removed!defqux(value_1,value_2)dosum(value_1,value_2)#<= imported function!endend#...Use examples...iex(1)>Foo.qux(1,2)3

  # After refactoring:defmoduleBardodefsum(v1,v2)dov1+v2endenddefmoduleFoododefqux(value_1,value_2)doBar.sum(value_1,value_2)#<= calling with a fully-qualified nameendend#...Use examples...iex(1)>Foo.qux(1,2)3

• Side-conditions:

  • This refactoring is free from any preconditions or postconditions. Considering that after this refactoring, the functions that were originally imported will be called with a fully-qualified name, even if the module that acted as the importer defines a function with the same name/arity as a function that was imported before the refactoring, no conflict will occur.

▲ back to Index

• Category: Traditional Refactorings.

• Motivation: This refactoring is the inverse ofRemove import attributes. Recall that Remove import attributes allows you to removeimport directives from a module, replacing all calls to imported functions with fully-qualified name calls (Module.function(args)). In contrast, Introduce import focuses on replacing fully-qualified name calls of functions from other modules with calls that use only the name of the imported functions.

• Examples: To better understand, take a look at the example inRemove import attributes in reverse order, that is,# After refactoring: -># Before refactoring:.

• Side-conditions:

  • When a moduleFoo is importing functions from a moduleBar, the moduleFoo must not have any previously defined functions with the same names/arity as the functions imported fromBar, thus avoiding conflicts;

  • Additionally, the moduleFoo must not have previously imported functions defined in other modules that have the same name/arity as the functions imported fromBar.

  This side condition is based on definitions provided by members of the RefactorErl project, as described in the following link:[1]

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: The divide-and-conquer pattern refers to a computation in which a problem is recursively divided into independent subproblems, and then the subproblems' solutions are combined to obtain the solution of the original problem. Such a computation pattern can be easily parallelized because we can work on the subproblems independently and in parallel. This refactoring aims to restructure functions that utilize the divide-and-conquer pattern, making parallelization easier. Specifically, this refactoring allows us to partition the branches of acase statement in a divide-and-conquer function into two categories:(1) the base cases, and(2) the recursive cases. This restructuring replaces the originalcase statement with fourcase statements.

• Examples: The following code examples illustrate a refactoring of the merge sort algorithm. Prior to the refactoring, themerge_sort/1 function had only a singlecase statement to handle both the base case and the recursive case.

  # Before refactoring:defmoduleFoododefmerge_sort(list)docaselistdo[]->[][h]->[h]_->half=length(list)|>div(2)right=merge_sort(Enum.take(list,half))left=merge_sort(Enum.drop(list,half))merge(right,left)endendend#...Use examples...iex(1)>Foo.merge_sort([3,20,9,2,7,99,80,30])[2,3,7,9,20,30,80,99]

  After refactoring, thiscase statement is replaced by four separatecase statements, each with its respective role:

  • (1 and 2) Determine whether the instance is a base case (true) or a recursive case (false);

  • (3 and 4) Define which specific base case or recursive case we are dealing with, respectively.

  # After refactoring:defmoduleFoododefmerge_sort(list)dois_base=caselistdo#<= role 1[]->true[_h]->true_->falseendcaseis_basedo#<= role 2true->caselistdo#<= role 3[]->[][h]->[h]endfalse->caselistdo#<= role 4_->half=length(list)|>div(2)right=merge_sort(Enum.take(list,half))left=merge_sort(Enum.drop(list,half))merge(right,left)endendendend#...Use examples...iex(1)>Foo.merge_sort([3,20,9,2,7,99,80,30])[2,3,7,9,20,30,80,99]

• Side-conditions:

  • The head expression of the originalcase statement (e.g.,case list do) must be pure before refactoring. In other words, this expression should not contain side effects, such as I/O operations, persist data in database, update GUI state, sending/receiving messages, etc.

  This side condition is based on definitions written by Tamás Kozsiket al. in this paper:[1]

▲ back to Index

• Category: Traditional Refactoring.

• Motivation: The divide-and-conquer pattern refers to a computation in which a problem is recursively divided into independent subproblems, and then the subproblems' solutions are combined to obtain the solution of the original problem. Such a computation pattern can be easily parallelized because we can work on the subproblems independently and in parallel. This refactoring aims to restructure functions that utilize the divide-and-conquer pattern, making parallelization easier. More precisely, this refactoring moves an expression outside of acase statement when it is repeated at the end of all branches.

• Examples: The following code examples demonstrate this refactoring. Before the refactoring, thebar/2 function has acase statement with two branches. At the end of both branches, the expressionInteger.is_odd(value) is repeated.

  # Before refactoring:defmoduleFoododefbar(confirm,list)docaseconfirmdotrue->value=Enum.at(list,0)Integer.is_odd(value)false->value=Enum.at(list,length(list)-1)Integer.is_odd(value)endendend#...Use examples...iex(1)>Foo.bar(true,[6,5,4,3,2,1])falseiex(2)>Foo.bar(false,[6,5,4,3,2,1])true

  After the refactoring,bar/2 retains the same behavior, but now with the expressionInteger.is_odd(value) moved outside thecase statement.

  # After refactoring:defmoduleFoododefbar(confirm,list)dovalue=caseconfirmdotrue->Enum.at(list,0)false->Enum.at(list,length(list)-1)endInteger.is_odd(value)#<= out of case!endend#...Use examples...iex(1)>Foo.bar(true,[6,5,4,3,2,1])falseiex(2)>Foo.bar(false,[6,5,4,3,2,1])true

• Side-conditions:

  • The expressions at the end of the originalcase branches should be lexically identical.

  This side condition is based on definitions written by Tamás Kozsiket al. in this paper:[1]

▲ back to Index

• Category: Traditional Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: When we know that a given data can have anil value and we need to return a default value if that data is indeednil, instead of usingis_nil/1 and anif-else block to test this condition and return the required value, we can utilize a short-circuit operator|| based on truthness conditions. This refactoring reduces the number of lines required for such an operation, maintaining clean and self-explanatory code.

• Examples: In the following code, we use the built-in Elixir functionis_nil/1 to check if the value ofprice isnil and then return a default value if that is true. Otherwise, the original value ofprice is returned.

  # Before refactoring:defdefault(price)doifis_nil(price)do"$100"elsepriceendend

  We can refactor thedefault/1 function by simplifying the null check forprice, using only a test based on truthness conditions, as shown below.

  # After refactoring:defdefault(price)doprice||"$100"end

  In Elixir, the atomsnil andfalse are treated asfalsy values, whereas everything else is treated as atruthy value. When we use a short-circuit operator|| based on truthiness conditions, it returns the first expression that isn'tfalsy, thus the refactored code preserves the behavior of the original.

  This example is based on an original code by Malreddy Ankanna. Source:link

▲ back to Index

• Category: Traditional Refactorings.

• Source: This refactoring emerged from a Grey Literature Review (GLR).

• Motivation: When dealing with a boolean expression consisting of multiple equality comparisons involving the same variable and logicalor operators, we can reduce the number of lines of code and enhance readability by utilizing thein operator and a list containing all possible valid values for the variable. The advantages of this refactoring are particularly derived from the removal of partially duplicated code.

• Examples: In the following code, we have a boolean expression that checks if anuser holds any of the four possible positions. If it is true for any of the positions, thedo_something/0 function is called. Otherwise, the code invokes thedo_something_else/0 function.

  # Before refactoring:ifuser=="admin"oruser=="super_admin"oruser=="agent"oruser=="super_agent"dodo_something()elsedo_something_else()end

  As shown next, we can refactor this code by reducing the size of the boolean expression in question and improving readability through the removal of duplicated code.

  # After refactoring:ifuserin["admin","super_admin","agent","super_agent"]dodo_something()elsedo_something_else()end

  This example is based on an original code by Malreddy Ankanna. Source:link