Code Smells 1.

Slides:



Advertisements
Similar presentations
12-Dec-14 Refactoring IV. Previously discussed bad smells Duplicated code — and other forms of redundancy Long method — use short methods that delegate.
Advertisements

Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
Test-Driven Development and Refactoring CPSC 315 – Programming Studio.
© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 
You want me to do what??? Refactoring legacy applications aka : fixing someone else’s “bad” code Niel Zeeman Team Foundation Consulting
Refactoring and Code Smells
Gregor Gisler-Merz BrownBag Session Refactoring.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Lectures 17 and 18 A Refactoring Micro-Example FOR0383 Software Quality Assurance 5/16/20151Dr Andy Brooks Refactoring is really easy using this tool.
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
1 Software Maintenance and Evolution CSSE 575: Session 1, Part 4 Even more Bad Smells in Code Steve Chenoweth Office Phone: (812) Cell: (937)
Introduction to Refactoring Excerpted from ‘What is Refactoring?’ by William C. Wake and Refactoring: Improving the Design of Existing Code by Martin Fowler.
George Blank University Lecturer. REFACTORING Improving the Design of Existing Code Supplement to Ian Sommerville, Software Engineering, Chapter 20 Prepared.
XP and Refactoring David Talby. Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
CSE 413 Programming Languages & Implementation Hal Perkins Autumn 2012 Ruby: Multiple Inheritance, Interfaces, Mixins 1.
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Refactoring Cristescu Marilena. Definitions Loose Usage: Reorganize a program(or something) As a noun: a change made to the internal structure of some.
Software Refactoring Part I: Introduction Bartosz Walter Advanced Object-Oriented Design Lecture 5.
Designing with Procedures 1. Designing a Program with Procedures If the code for your program is going to be less than one page, normally don’t bother;
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
Refactoring - A disciplined approach to rework for better design.
Refactoring Improving the structure of existing code Refactoring1.
17-Oct-15 Refactoring. 2 Refactoring is: restructuring (rearranging) code......in a series of small, semantics-preserving transformations (i.e. the code.
Refactoring (continued) Source: "Refactoring: Improving the Design of Existing Code", Martin Fowler.
When and How to Refactor? Refactoring Patterns Alexander Vakrilov Telerik Corporation Senior Developer and Team Leader.
Improving the Quality of Existing Code Svetlin Nakov Telerik Corporation
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 12-5 Software Engineering Design Goals.
Refactoring1 Improving the structure of existing code.
Refactoring Deciding what to make a superclass or interface is difficult. Some of these refactorings are helpful. Some research items include Inheritance.
Introduction to Refactoring Jim Cooper Falafel Software.
Informatics 122 Software Design II
Lecture 12 March 16, The Scope of a Variable What if there are two variables with the same name? –A local or block-local variable can have the same.
1 CSC/ECE 517 Fall 2010 Lec. 3 Overview of Eclipse Lectures Lecture 2 “Lecture 0” Lecture 3 1.Overview 2.Installing and Running 3.Building and Running.
Incremental Design Why incremental design? Goal of incremental design Tools for incremental design  UML diagrams  Design principles  Design patterns.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
Refactoring: Code Smells. Admin Notes REGISTER FOR BLACKBOARD Watch blackboard site for updates on class as hurricane season approaches.
Refactoring. Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative.
Refactoring 2. Admin Blackboard Quiz Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
Refactoring II Dealing with Polymorphism. Switch in Rental Switches on Movie! class Rental … public double getCharge() { double result = 0; switch (getMovie().getPriceCode()){
Module 3. Smells Between Classes Course: Refactoring.
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 1 Refactoring Principles Steve Chenoweth Office Phone: (812) Cell: (937)
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 3 Dealing with Generalization Steve Chenoweth Office Phone: (812) Cell: (937)
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Refactoring1 Improving the structure of existing code.
Pertemuan 12 Refactoring Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
Software Construction and Evolution - CSSE 375 Dealing with Generalization Steve and Shawn Left – In the 1990 movie “The Freshman,” Matthew Broderick,
Module 9. Dealing with Generalization Course: Refactoring.
A (Very) Simple Example Consolidate duplicate conditional fragments if (isSpecialDeal()) { total = price * 0.95; send (); } else { total = price * 0.98;
Principles and examples
Steve Chenoweth Office Phone: (812) Cell: (937)
Module Road Map Refactoring Why Refactoring? Examples
Steve Chenoweth Office Phone: (812) Cell: (937)
Steve Chenoweth Office Phone: (812) Cell: (937)
Types of Programming Languages
Refactoring and Code Smells
Understanding Inheritance
بازآرایی برنامه Code Refactoring
Overview of Eclipse Lectures
Improving the structure of existing code
Refactoring and Code Smells
Refactoring Types Blake Duncan.
Refactoring.
Refactoring and Code Smells
Refactoring and Code Smells
Refactoring.
Refactoring and Code Smells
Presentation transcript:

Code Smells 1

What are Code Smells? “[…] certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring.” Fowler They are clear signs that your design is starting to decay Long term decay leads to “software rot”

Code Smells Duplicated code Long method Large class Long parameter list Message chain Feature envy Data class Switch statements Speculative generality Temporary field Refused bequest

Duplicate code Duplicate methods in subclasses Move to a superclass (consider creating one if it does not exist) Duplicate expressions in the same class Extract as a new method Duplicate expression in different classes Extract method, move to a common component

Long method Symptoms Will not fit on one page Cannot think of the whole Comments that introduce sections of the method Extract parts of the method as a new method Candidates include Loop body Place(s) that include comments Branches of if statements

Large class Symptoms More than a couple dozen methods More than half a dozen fields Split into component classes Extract superclass If using switch statement, split into subclasses

Single Responsibility Principle A class should only have one responsibility In other words: it should have only one reason to change

Long parameter list Introduce parameter object Only worthwhile if there are several methods with the same parameter list, and they call each other

Message Chain Symptoms Anything that looks like this customer.Address.State window.BoundingBox.Origin.X When it could look like this customer.State window.LeftBoundary

Law of Demeter Only talk to your immediate friends It allows you to use objects that were obtained via Parameters of the method Fields of the class Objects created in the method Global variables

Feature envy Symptoms Code that wished it was in another class It uses data from another class From Teacher.Classes.Add(class); Teacher.ClassLoad += 1; To teacher.AddClass(class);

Data class Symptoms Class that has no methods except for Property getters and setters Look for missing methods (Feature envy?) and move them to the class Look for classes using the data and merge in with those

Switch statement Symptoms Sign of missing polymorphism Replace with A method call and make a subclass for each case

Speculative generality Symptoms Interfaces/abstract classes that are implemented by only one class Unnecessary delegation Unused parameters

Temporary field Symptoms Instance variable is only used during part of the lifetime of an object i.e. it is only used while the object is initialized Move variable into another object (perhaps a new class)

Refused bequest Symptoms A class refuses bequest if it inherits another class but only overrides or specializes a small number of methods Parent class is too large Break class into separate classes Push down or pull up some of the methods Child class is not using the methods Inheritance is no needed; convert inheritance into composition

Other smells Non-localized plans Too many bugs Too hard to understand Too hard to change

Non-localized plan Adding a feature requires a plan. If adding a feature requires changing many parts of a program, it is called a non-localized plan e.g., Parallel class hierarchies – adding a class in one class hierarchy requires adding a class in another Example A new item class requires a new ItemFactory class

How to refactor a Non-localized plan Make a new object that represents everything that changes Methods that change together should stay together Many patterns address this kind of problem

Too many bugs If one part of the system has more than its share of the bugs, there is probably a good reason A growing number of bugs is the sign of software rot Redesign, rewrite, refactor

Too hard to understand Hard to fix bugs because you don’t understand the code Hard to change the code because you don’t understand it

Too hard to change Because of a lack of tests Because of (undocumented) dependencies Global variables Very large modules Importing too many classes (high coupling) Because of duplication or non-localized plans

It’s a sense “You will have to develop your own sense of how many instance variables are too many instance variables and how many lines of code in a method are too many lines.” Fowler

?

References