Delta analysis
Reviewed on Jan 28, 17:01
plot_map increases from 93 to 103 lines of code, threshold = 70
Overly long functions make the code harder to read. The recommended maximum function length for the Python language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.
We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern.
plot_image increases from 79 to 84 lines of code, threshold = 70
Overly long functions make the code harder to read. The recommended maximum function length for the Python language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.
We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern.
add_map_inset increases from 75 to 76 lines of code, threshold = 70
Overly long functions make the code harder to read. The recommended maximum function length for the Python language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.
We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern.
This module has a mean cyclomatic complexity of 4.03 across 40 functions. The mean complexity threshold is 4
Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.
Cyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).
You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:
Modularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a DECOMPOSE CONDITIONAL refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.
_expand_with_scan_mode has a cyclomatic complexity of 14, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
This module has a mean cyclomatic complexity of 5.86 across 7 functions. The mean complexity threshold is 4
Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.
Cyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).
You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:
Modularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a DECOMPOSE CONDITIONAL refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.
The average number of function arguments in this module is 4.43 across 7 functions. The average arguments threshold is 4.00
This code health issue is measured as the average number of function arguments across the whole file. A function with many arguments can be simplified either by a) splitting the function if it has too many responsibilities, or b) by introducing an abstraction (class, record, struct, etc.) which encapsulates the arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
CustomFacetGrid.map_to_axes has 1 complex conditionals with 2 branches, threshold = 2
A complex conditional is an expression inside a branch such as an if
-statmeent which consists of multiple, logical operations. Example: if (x.started() && y.running())
.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.
Apply the DECOMPOSE CONDITIONAL refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,16 +1,34 @@ |
function messageReceived(message, timeReceived) { |
// Ignore all messages which aren't from known customers: |
if (!message.sender && |
customers.getId(message.name) == null) { |
// Refactoring #1: encapsulate the business rule in a |
// function. A clear name replaces the need for the comment: |
if (!knownCustomer(message)) { |
log('spam received -- ignoring'); |
return; |
} |
// Provide an auto-reply when outside business hours: |
if ((timeReceived.getHours() > 17) || |
(timeReceived.getHours() < 8)) { |
// Refactoring #2: encapsulate the business rule. |
// Again, note how a clear function name replaces the |
// need for a code comment: |
if (outsideBusinessHours(timeReceived)) { |
return autoReplyTo(message); |
} |
pingAgentFor(message); |
} |
function outsideBusinessHours(timeReceived) { |
// Refactoring #3: replace magic numbers with |
// symbols that communicate with the code reader: |
const closingHour = 17; |
const openingHour = 8; |
const hours = timeReceived.getHours(); |
// Refactoring #4: simple conditional rules can |
// be further clarified by introducing a variable: |
const afterClosing = hours > closingHour; |
const beforeOpening = hours < openingHour; |
// Yeah -- look how clear the business rule is now! |
return afterClosing || beforeOpening; |
} |
_get_scan_modes_datasets_and_closers has a cyclomatic complexity of 17, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
open_datatree has a cyclomatic complexity of 9, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
open_dataset increases from 125 to 127 lines of code, threshold = 70
Overly long functions make the code harder to read. The recommended maximum function length for the Python language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.
We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern.
open_raw_datatree has 5 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
apply_cf_decoding has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is one single, nested block per function
A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.
A bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is levels of conditionals.
Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the Bumpy Road code health issue.
A Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The EXTRACT FUNCTION refactoring is the primary response.
The module contains 2 functions with similar structure: open_granule_dataset,open_granule_datatree
Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.
A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. Read More
Once you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.
open_granule_datatree has 81 lines, threshold = 70
Overly long functions make the code harder to read. The recommended maximum function length for the Python language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.
We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern.
open_granule_dataset has 76 lines, threshold = 70
Overly long functions make the code harder to read. The recommended maximum function length for the Python language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.
We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern.
_handle_unstack_non_dim_coords has 6 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
unstack_datarray_dimension has 5 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
unstack_dataset_dimension has 5 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
unstack_dimension has 5 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_cross_section increases in cyclomatic complexity from 10 to 14, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
_get_x_axis_options has a cyclomatic complexity of 9, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
_get_x_axis_options has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is one single, nested block per function
A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health.
A bumpy code road represents a lack of encapsulation which becomes an obstacle to comprehension. In imperative languages there’s also an increased risk for feature entanglement, which leads to complex state management. CodeScene considers the following rules for the code health impact: 1) The deeper the nested conditional logic of each bump, the higher the tax on our working memory. 2) The more bumps inside a function, the more expensive it is to refactor as each bump represents a missing abstraction. 3) The larger each bump – that is, the more lines of code it spans – the harder it is to build up a mental model of the function. The nesting depth for what is considered a bump is levels of conditionals.
Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the Bumpy Road code health issue.
A Bumpy Road often suggests that the function/method does too many things. The first refactoring step is to identify the different possible responsibilities of the function. Consider extracting those responsibilities into smaller, cohesive, and well-named functions. The EXTRACT FUNCTION refactoring is the primary response.
create_quicklooks_datasets has 6 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
This module has a mean cyclomatic complexity of 4.09 across 11 functions. The mean complexity threshold is 4
Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.
Cyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).
You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:
Modularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a DECOMPOSE CONDITIONAL refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.
The module contains 2 functions with similar structure: retrieve_polarization_difference,retrieve_polarization_ratio
Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.
A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. Read More
Once you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.
_np_pesca_classification has a cyclomatic complexity of 9, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
This module has a mean cyclomatic complexity of 6.14 across 7 functions. The mean complexity threshold is 4
Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.
Cyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).
You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:
Modularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a DECOMPOSE CONDITIONAL refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.
_np_pesca_classification has 6 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
This module has at least 4 different responsibilities amongst its 19 functions, threshold = 4
Cohesion is a measure of how well the elements in a file belong together. CodeScene measures cohesion using the LCOM4 metric (Lack of Cohesion Measure). With LCOM4, the functions inside a module are related if a) they access the same data members, or b) they call each other. High Cohesion is desirable as it means that all functions are related and likely to represent the same responsibility. Low Cohesion is problematic since it means that the module contains multiple behaviors. Low Cohesion leads to code that's harder to understand, requires more tests, and very often become a coordination magnet for developers.
Look to modularize the code by splitting the file into more cohesive units; functions that belong together should still be located together. A common refactoring is EXTRACT CLASS.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -2,8 +2,10 @@ |
var userLayer = connectUsers(myConnectionProperties); |
var chessEngine = startEngine(gameProperties); |
// [Refactoring: moved the data related to chess to a new chessGame.js module] |
// The module contains login related functionality that forms one behaviour: all |
// code is related since it either a) uses the same data, or b) calls the same functions. |
export function login(newUser) { |
val authenticated = userLayer.authenticate(newUser); |
traceLoginFor(authenticated); |
@@ -19,11 +21,6 @@ function traceLogin(user) { |
// ...some code... |
} |
// playChess seems like a very unrelated responsibility. |
// Should it really be within the same module? |
export function playChess(loggedInUser) { |
var board = chessEngine.newBoard(); |
return newGameOn(board, loggedInUser); |
} |
// [Refactoring: moved playChess to a new chessGame.js module |
// As a result of this refactoring, the module maintains a |
// single behavior where all code and data is related: high cohesion.] |
find_polarization_pairs has a cyclomatic complexity of 9, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
find_polarization_pairs has 1 complex conditionals with 2 branches, threshold = 2
A complex conditional is an expression inside a branch such as an if
-statmeent which consists of multiple, logical operations. Example: if (x.started() && y.running())
.Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them.
Apply the DECOMPOSE CONDITIONAL refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,16 +1,34 @@ |
function messageReceived(message, timeReceived) { |
// Ignore all messages which aren't from known customers: |
if (!message.sender && |
customers.getId(message.name) == null) { |
// Refactoring #1: encapsulate the business rule in a |
// function. A clear name replaces the need for the comment: |
if (!knownCustomer(message)) { |
log('spam received -- ignoring'); |
return; |
} |
// Provide an auto-reply when outside business hours: |
if ((timeReceived.getHours() > 17) || |
(timeReceived.getHours() < 8)) { |
// Refactoring #2: encapsulate the business rule. |
// Again, note how a clear function name replaces the |
// need for a code comment: |
if (outsideBusinessHours(timeReceived)) { |
return autoReplyTo(message); |
} |
pingAgentFor(message); |
} |
function outsideBusinessHours(timeReceived) { |
// Refactoring #3: replace magic numbers with |
// symbols that communicate with the code reader: |
const closingHour = 17; |
const openingHour = 8; |
const hours = timeReceived.getHours(); |
// Refactoring #4: simple conditional rules can |
// be further clarified by introducing a variable: |
const afterClosing = hours > closingHour; |
const beforeOpening = hours < openingHour; |
// Yeah -- look how clear the business rule is now! |
return afterClosing || beforeOpening; |
} |
get_rgb_composites_receipts has 325 lines, threshold = 70
Overly long functions make the code harder to read. The recommended maximum function length for the Python language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method.
We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern.
find_polarization_pairs has a nested complexity depth of 5, threshold = 4
Deep nested logic means that you have control structures like if-statements or loops inside other control structures. Deep nested logic increases the cognitive load on the programmer reading the code. The human working memory has a maximum capacity of 3-4 items; beyond that threshold, we struggle with keeping things in our head. Consequently, deep nested logic has a strong correlation to defects and accounts for roughly 20% of all programming mistakes.
CodeScene measures the maximum nesting depth inside each function. The deeper the nesting, the lower the code health. The threshold for the Python language is 5 levels of nesting.
Occassionally, it's possible to get rid of the nested logic by Replacing Conditionals with Guard Clauses.
Another viable strategy is to identify smaller building blocks inside the nested chunks of logic and extract those responsibilities into smaller, cohesive, and well-named functions. The EXTRACT FUNCTION refactoring explains the steps.
plot_xr_imshow has a cyclomatic complexity of 10, threshold = 9
A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9.
There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -1,15 +1,20 @@ |
function postItem(item) { |
if (!item.id) { |
if (item.x != null && item.y != null) { |
post(item); |
} else { |
throw Error("Item must have x and y"); |
} |
// extract a separate function for creating new item |
postNew(item); |
} else { |
if (item.x < 10 && item.y > 25) { |
put(item); |
} else { |
throw Error("Item must have an x and y value between 10 and 25"); |
} |
// and one for updating existing items |
updateItem(item); |
} |
} |
function postNew(item) { |
validateNew(item); |
post(item); |
} |
function updateItem(item) { |
validateUpdate(item); |
put(item); |
} |
The average number of function arguments increases from 4.44 to 4.93, threshold = 4.00
This code health issue is measured as the average number of function arguments across the whole file. A function with many arguments can be simplified either by a) splitting the function if it has too many responsibilities, or b) by introducing an abstraction (class, record, struct, etc.) which encapsulates the arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_xr_imshow increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_plot_image increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_plot_image_facetgrid increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_image increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_map increases from 12 to 14 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_map_mesh increases from 10 to 12 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_map_mesh_centroids increases from 10 to 12 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
add_map_inset increases from 5 to 6 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
initialize_cartopy_plot has 6 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
The lines of code increases from 777 to 852, improve code health by reducing it to 600
This module has 852 lines of code (comments stripped away). This puts the module at risk of evolving into a Brain Class. Brain Classes are problematic since changes become more complex over time, harder to test, and challenging to refactor. Act now to prevent future maintenance issues.
Look for opportunities to modularize the design. This is done by identifying groups of functions that represent different responsibilities and/or operate on different data. Once you have identified the different responsibilities, then use refactorings like EXTRACT CLASS.
The number of functions increases from 100 to 107, threshold = 75
GPM_Base_Accessor.collocate increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Base_Accessor.plot_transect_line increases from 8 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Base_Accessor.plot_swath increases from 8 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Base_Accessor.plot_swath_lines increases from 9 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Base_Accessor.plot_map_mesh increases from 9 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Base_Accessor.plot_map_mesh_centroids increases from 9 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Dataset_Accessor.plot_map increases from 12 to 14 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Dataset_Accessor.plot_image increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_Dataset_Accessor.plot_cross_section increases from 10 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_DataArray_Accessor.plot_map increases from 11 to 13 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_DataArray_Accessor.plot_image increases from 8 to 9 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
GPM_DataArray_Accessor.plot_cross_section increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
collocate_product increases from 10 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_gdf_map has 9 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
The average number of function arguments increases from 4.10 to 4.30, threshold = 4.00
This code health issue is measured as the average number of function arguments across the whole file. A function with many arguments can be simplified either by a) splitting the function if it has too many responsibilities, or b) by introducing an abstraction (class, record, struct, etc.) which encapsulates the arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
The lines of code increases from 694 to 698, improve code health by reducing it to 600
This module has 698 lines of code (comments stripped away). This puts the module at risk of evolving into a Brain Class. Brain Classes are problematic since changes become more complex over time, harder to test, and challenging to refactor. Act now to prevent future maintenance issues.
Look for opportunities to modularize the design. This is done by identifying groups of functions that represent different responsibilities and/or operate on different data. Once you have identified the different responsibilities, then use refactorings like EXTRACT CLASS.
The mean cyclomatic complexity increases from 4.42 to 4.59, threshold = 4
Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.
Cyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).
You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:
Modularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a DECOMPOSE CONDITIONAL refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.
_try_open_granule increases from 7 to 8 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
open_dataset increases from 13 to 14 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_get_scan_modes_datasets_and_closers has 5 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
open_datatree has 14 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
get_scan_modes_datasets has 8 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
open_granule_dataset has 8 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
open_granule_datatree has 8 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_range_distance increases from 7 to 9 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_map increases from 10 to 12 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
open_dataset_1b_ka_fs increases from 9 to 10 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
introduced similar code in: test_locate_max_value,test_locate_min_value
Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.
A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. Read More
Once you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.
The lines of code increases from 700 to 710, improve code health by reducing it to 600
This module has 710 lines of code (comments stripped away). This puts the module at risk of evolving into a Brain Class. Brain Classes are problematic since changes become more complex over time, harder to test, and challenging to refactor. Act now to prevent future maintenance issues.
Look for opportunities to modularize the design. This is done by identifying groups of functions that represent different responsibilities and/or operate on different data. Once you have identified the different responsibilities, then use refactorings like EXTRACT CLASS.
The number of different responsibilities increases from 6 to 7, threshold = 4
Cohesion is a measure of how well the elements in a file belong together. CodeScene measures cohesion using the LCOM4 metric (Lack of Cohesion Measure). With LCOM4, the functions inside a module are related if a) they access the same data members, or b) they call each other. High Cohesion is desirable as it means that all functions are related and likely to represent the same responsibility. Low Cohesion is problematic since it means that the module contains multiple behaviors. Low Cohesion leads to code that's harder to understand, requires more tests, and very often become a coordination magnet for developers.
Look to modularize the code by splitting the file into more cohesive units; functions that belong together should still be located together. A common refactoring is EXTRACT CLASS.
To get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes.
@@ -2,8 +2,10 @@ |
var userLayer = connectUsers(myConnectionProperties); |
var chessEngine = startEngine(gameProperties); |
// [Refactoring: moved the data related to chess to a new chessGame.js module] |
// The module contains login related functionality that forms one behaviour: all |
// code is related since it either a) uses the same data, or b) calls the same functions. |
export function login(newUser) { |
val authenticated = userLayer.authenticate(newUser); |
traceLoginFor(authenticated); |
@@ -19,11 +21,6 @@ function traceLogin(user) { |
// ...some code... |
} |
// playChess seems like a very unrelated responsibility. |
// Should it really be within the same module? |
export function playChess(loggedInUser) { |
var board = chessEngine.newBoard(); |
return newGameOn(board, loggedInUser); |
} |
// [Refactoring: moved playChess to a new chessGame.js module |
// As a result of this refactoring, the module maintains a |
// single behavior where all code and data is related: high cohesion.] |
The lines of code increases from 872 to 926, improve code health by reducing it to 600
This module has 926 lines of code (comments stripped away). This puts the module at risk of evolving into a Brain Class. Brain Classes are problematic since changes become more complex over time, harder to test, and challenging to refactor. Act now to prevent future maintenance issues.
Look for opportunities to modularize the design. This is done by identifying groups of functions that represent different responsibilities and/or operate on different data. Once you have identified the different responsibilities, then use refactorings like EXTRACT CLASS.
introduced similar code in: locate_max_value,locate_min_value
Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.
A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. Read More
Once you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.
The mean cyclomatic complexity increases from 5.57 to 6.57, threshold = 4
Overall Code Complexity is measured by the mean cyclomatic complexity across all functions in the file. The lower the number, the better.
Cyclomatic complexity is a function level metric that measures the number of logical branches (if-else, loops, etc.). Cyclomatic complexity is a rough complexity measure, but useful as a way of estimating the minimum number of unit tests you would need. As such, prefer functions with low cyclomatic complexity (2-3 branches).
You address the overall cyclomatic complexity by a) modularizing the code, and b) abstract away the complexity. Let's look at some examples:
Modularizing the Code: Do an X-Ray and inspect the local hotspots. Are there any complex conditional expressions? If yes, then do a DECOMPOSE CONDITIONAL refactoring. Extract the conditional logic into a separate function and put a good name on that function. This clarifies the intent and makes the original function easier to read. Repeat until all complex conditional expressions have been simplified.
The average number of function arguments increases from 4.57 to 5.00, threshold = 4.00
This code health issue is measured as the average number of function arguments across the whole file. A function with many arguments can be simplified either by a) splitting the function if it has too many responsibilities, or b) by introducing an abstraction (class, record, struct, etc.) which encapsulates the arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_cross_section increases from 10 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_transect_line increases from 9 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_plot_grid_map_cartopy increases from 11 to 13 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_plot_grid_map_facetgrid increases from 11 to 13 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_grid_map increases from 11 to 13 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_grid_mesh increases from 10 to 12 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
The average number of function arguments increases from 7.09 to 8.18, threshold = 4.00
This code health issue is measured as the average number of function arguments across the whole file. A function with many arguments can be simplified either by a) splitting the function if it has too many responsibilities, or b) by introducing an abstraction (class, record, struct, etc.) which encapsulates the arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_swath_lines increases from 10 to 12 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_swath increases from 9 to 11 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_plot_orbit_map_cartopy increases from 11 to 13 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_plot_orbit_map_facetgrid increases from 11 to 13 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_orbit_map increases from 11 to 13 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
plot_orbit_mesh increases from 10 to 12 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
_subset increases from 5 to 6 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
sel has 5 arguments, threshold = 4
Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments.
The threshold for the Python language is 4 function arguments.
Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept.
The lines of code decreases from 1112 to 1054, improve code health by reducing it to 600
_get_orientation_location is no longer above the threshold for cyclomatic complexity
_get_orientation_location is no longer above the threshold for logical blocks with deeply nested code
get_inset_bounds is no longer above the threshold for number of arguments
_plot_gdf_map is no longer above the threshold for number of arguments
The lines of code decreases from 742 to 741, improve code health by reducing it to 600
CustomFacetGrid.map_dataarray decreases in cyclomatic complexity from 11 to 10, threshold = 9
The mean cyclomatic complexity in this module is no longer above the threshold
The average number of function arguments is no longer above the threshold
_open_valid_granules is no longer above the threshold for number of arguments
_open_granule is no longer above the threshold for number of arguments
open_granule is no longer above the threshold for number of arguments
reduced similar code in: test_rename_dataset_dimensions,test_rename_datatree_dimensions
open_dataset_1b_ka_fs decreases from 88 to 76 lines of code, threshold = 70
reduced similar code in: test_get_max_value_point,test_get_min_value_point
The lines of code decreases from 692 to 682, improve code health by reducing it to 600
The number of functions decreases from 90 to 84, threshold = 75
reduced similar code in: get_max_value_point,get_min_value_point
The mean cyclomatic complexity decreases from 5.00 to 4.39, threshold = 4
The mean cyclomatic complexity decreases from 5.16 to 5.13, threshold = 4
The module no longer contains too many functions with similar structure