Return to Answer

added 199 characters in body

edited Jun 21, 2017 at 18:29

319
1
8

This is an example of Primitive Obsession - using primitive types for "simple" tasks that eventually become not so simple.

This may have started out as code that returned a bool to indicate success or failure, then turned into an int when there was a third state, and eventually became a whole list of nigh-undocumented error conditions.

The typical refactoring for this problem is to create a new class/struct/enum/object/whatever that can better represent the value in question. In this case, you might consider switching to an enum that contains the result conditions, or even a class that could contain a bool for success or failure, an error message, additional information, etc.

For more refactoring patterns that might be useful, have a look at Industrial Logic's Smells to Refactorings Cheatsheet.

This is an example of Primitive Obsession - using primitive types for "simple" tasks that eventually become not so simple.

This may have started out as code that returned a bool to indicate success or failure, then turned into an int when there was a third state, and eventually became a whole list of nigh-undocumented error conditions.

The typical refactoring for this problem is to create a new class/struct/enum/object/whatever that can better represent the value in question. In this case, you might consider switching to an enum that contains the result conditions, or even a class that could contain a bool for success or failure, an error message, additional information, etc.

This is an example of Primitive Obsession - using primitive types for "simple" tasks that eventually become not so simple.

This may have started out as code that returned a bool to indicate success or failure, then turned into an int when there was a third state, and eventually became a whole list of nigh-undocumented error conditions.

The typical refactoring for this problem is to create a new class/struct/enum/object/whatever that can better represent the value in question. In this case, you might consider switching to an enum that contains the result conditions, or even a class that could contain a bool for success or failure, an error message, additional information, etc.

For more refactoring patterns that might be useful, have a look at Industrial Logic's Smells to Refactorings Cheatsheet.

answered Jun 21, 2017 at 18:22

319
1
8

This is an example of Primitive Obsession - using primitive types for "simple" tasks that eventually become not so simple.

This may have started out as code that returned a bool to indicate success or failure, then turned into an int when there was a third state, and eventually became a whole list of nigh-undocumented error conditions.

The typical refactoring for this problem is to create a new class/struct/enum/object/whatever that can better represent the value in question. In this case, you might consider switching to an enum that contains the result conditions, or even a class that could contain a bool for success or failure, an error message, additional information, etc.