0% found this document useful (0 votes)
65 views40 pages

Pemrograman Lanjut: Code Smells: Dispensable

The document discusses various code smells that can occur in software design including rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, and opacity. It then describes specific code smells like dispensable code, duplicate code, speculative generality, dead code, data classes, and lazy classes. For each smell, it provides examples and potential refactoring techniques to improve code quality such as extracting variables, methods, renaming methods, pulling up fields or constructors, forming template methods, substituting algorithms, extracting superclasses or classes, consolidating conditionals, collapsing or inlining classes. It emphasizes the importance of removing unnecessary comments, classes, fields, parameters and methods to create cleaner code.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
65 views40 pages

Pemrograman Lanjut: Code Smells: Dispensable

The document discusses various code smells that can occur in software design including rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, and opacity. It then describes specific code smells like dispensable code, duplicate code, speculative generality, dead code, data classes, and lazy classes. For each smell, it provides examples and potential refactoring techniques to improve code quality such as extracting variables, methods, renaming methods, pulling up fields or constructors, forming template methods, substituting algorithms, extracting superclasses or classes, consolidating conditionals, collapsing or inlining classes. It emphasizes the importance of removing unnecessary comments, classes, fields, parameters and methods to create cleaner code.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 40

PEMROGRAMAN LANJUT

Code Smells: Dispensable


Oleh
Tri Hadiah Muliawati
Politeknik Elektronika Negeri Surabaya
2021
Designs Smells
1. Rigidity – hard to change
The system is hard to change because every change forces many other changes to other parts
of the system
2. Fragility – easy to break
Changes cause the system to break in places that have no conceptual relationship to the part
that was changed
3. Immobility – hard to reuse
It is hard to disentangle the system into components that can be reused in other systems
4. Viscosity – hard to do the right thing
Doing the things right is harder than doing the things wrong
5. Needless Complexity – overdesign
The design contains infrastructure that adds no direct benefit
6. Needless Repetition – mouse abuse
The design contains repeating structures that could be unified under a single abstraction
7. Opacity – disorganized expression
It is hard to read and understand. It does not express its intent well
Code Smells
• Dispensable
• Object Oriented Abuser
• Bloater
• Change Preventer
• Coupler
Dispensable
something pointless and unneeded whose absence would make the
code cleaner, more efficient and easier to understand
Dispensable
• Comments
• Duplicate Code
• Speculative Generality
• Dead Code
• Data Class
• Lazy Class
Comments
Comments
• The older a comment is, and the farther away it is from the code it describes, the
more likely it is to be just plain wrong. Since, programmers can’t realistically
maintain them.
• Don’t use a comment when you can use a function or a variable
Comments
• Misleading comments
• Mandated comments
Comments
• Journal comments
Comments
• Scary noise comments • Position markers
• Commented-out code
• Attribution and bylines

• Closing brace comments


Refactoring
• Extract variable
If a comment is intended to explain a complex expression, the expression should
be split into understandable subexpressions.
Refactoring
• Extract method
If a comment explains a section of code, this section can be turned into a
separate method. In addition, extract method can also be used when the
extracted expression is used in other places in your code.
Refactoring
• Rename method
If a method has already been extracted, but comments are still necessary to
explain what the method does, give the method a self-explanatory name
Good Comments
However, some comments are necessary:
• Java docs in Public APIs
• Legal Comments

• Informative Comments
it might have been better, and clearer, if this
code had been moved to a special class that
converted the formats of dates and times.
Then the comment would likely have been
superfluous.
Good Comments
However, some comments are necessary:
• Explanation of Intent

You might not agree with the programmer’s solution


to the problem, but at least you know what he was
trying to do.
Duplicate Code
Duplicate Code
• Two code fragments look almost identical
• It is aligned with one of programming principles, which is DRY (Do not
Repeat Yourself)
Refactoring
• Extract method
1. If the same code is found in two or more methods in the same
class.
2. If the same code is found in two subclasses of the same level.
followed by Pull Up Field for the fields used in the method that
you’re pulling up
Refactoring
• Pull up constructor body
If the same code is found in two subclasses of the same level and the
duplicate code is inside a constructor.
Refactoring
• Form template method
If the same code is found in two subclasses of the same level and the
duplicate code is similar but not completely identical.
Refactoring
• Substitute algorithm
If the same code is found in two subclasses of the same level and If
two methods do the same thing but use different algorithms, select
the best algorithm. It is aligned with one of programming principles,
which is KISS (Keep It Simple Stu***)
Refactoring
• Extract superclass
If duplicate code is found in two different classes and those classes
aren’t part of a hierarchy.
• Extract class
If duplicate code is found in two different classes, but it’s difficult or
impossible to create a superclass. Use the new component in the
other.
Refactoring
• Consolidate conditional expression
If a large number of conditional expressions are present and perform
the same code (differing only in their conditions)
Refactoring
• Consolidate duplicate conditional fragment
If Identical code can be found in all branches of a conditional
Speculative Generality
Speculative Generality
• If there is an unused class,
method, field or parameter
Refactoring
• Collapse Hierarchy
if a subclass is practically the same as its superclass.
Refactoring
• Inline method
When a method body is more obvious than the method itself.
Refactoring
• Remove parameter
When parameter isn’t used in the body of a method.
Dead Code
Dead Code
• A variable, parameter,
field, method or class
is no longer used
(usually because it’s
obsolete)
Data Class
Data Class
• A data class refers to a class
that contains only fields.
• These are simply containers
for data used by other
classes. These classes don’t
contain any additional
functionality and can’t
independently operate on
the data that they own.
Refactoring
• Encapsulate field and encapsulate collection
to hide them from direct access and require that access be performed
via getters and setters only
• Move method
Review the client code that uses the class. In case there is any
functionality that would be better located in the data class itself.
Lazy Class
Lazy Class
• if a class doesn’t do enough
to earn your attention, it
should be deleted
Refactoring
• Collapse hierarchy
• Inline class
References
• Martin, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship.
Pearson. 2008.
• Fowler, Martin. Refactoring: Improving the Design of Existing Code. Addison-
Wesley Professional, 1999.
• https://refactoring.guru/
• Rasyid Institute. Modul Workshop Clean Code. 2019.

You might also like