Code smell

Last updated

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. [1] [2] Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

Contents

The term was popularized by Kent Beck on WardsWiki in the late 1990s. [3] Usage of the term increased after it was featured in the 1999 book Refactoring: Improving the Design of Existing Code by Martin Fowler. [4] It is also a term used by agile programmers. [5]

Definition

One way to look at smells is with respect to principles and quality: "Smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality". [6] Code smells are usually not bugs; they are not technically incorrect and do not prevent the program from functioning. Instead, they indicate weaknesses in design that may slow down development or increase the risk of bugs or failures in the future. Bad code smells can be an indicator of factors that contribute to technical debt. [1] Robert C. Martin calls a list of code smells a "value system" for software craftsmanship. [7]

Contrary to these severe interpretations, Cunningham's original definition was that a smell is a suggestion that something may be wrong, not evidence that there is already a problem. [3]

Often the deeper problem hinted at by a code smell can be uncovered when the code is subjected to a short feedback cycle, where it is refactored in small, controlled steps, and the resulting design is examined to see if there are any further code smells that in turn indicate the need for more refactoring. From the point of view of a programmer charged with performing refactoring, code smells are heuristics to indicate when to refactor, and what specific refactoring techniques to use. Thus, a code smell is a driver for refactoring.

Factors such as the understandability of code, how easy it is to be modified, the ease in which it can be enhanced to support functional changes, the code's ability to be reused in different settings, how testable the code is, and code reliability are factors that can be used to identify code smells. [8]

A 2015 study [1] utilizing automated analysis for half a million source code commits and the manual examination of 9,164 commits determined to exhibit "code smells" found that:

Tools such as Checkstyle, PMD, FindBugs, and SonarQube can automatically identify code smells.

See also

Related Research Articles

Computer programming or coding is the composition of sequences of instructions, called programs, that computers can follow to perform tasks. It involves designing and implementing algorithms, step-by-step specifications of procedures, by writing code in one or more programming languages. Programmers typically use high-level programming languages that are more easily intelligible to humans than machine code, which is directly executed by the central processing unit. Proficient programming usually requires expertise in several different subjects, including knowledge of the application domain, details of programming languages and generic code libraries, specialized algorithms, and formal logic.

<span class="mw-page-title-main">Martin Fowler (software engineer)</span> American software developer, author and public speaker

Martin Fowler is a British software developer, author and international public speaker on software development, specialising in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming.

In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

Unit testing, a.k.a. component or module testing, is a form of software testing by which isolated source code is tested to validate expected behavior.

Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which consists of both design documentation and undocumented concepts.

The following outline is provided as an overview of and topical guide to software engineering:

Agile software development is the mindset for developing software that derives from values agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

"You aren't gonna need it" (YAGNI) is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary. Other forms of the phrase include "You aren't going to need it" (YAGTNI) and "You ain't gonna need it".

In the context of software engineering, software quality refers to two related but distinct notions:

Thoughtworks is a publicly-traded, global technology company with 49 offices in 18 countries. It provides software design and delivery, and tools and consulting services. The company is closely associated with the movement for agile software development, and has contributed to open source products. Thoughtworks' business includes Digital Product Development Services, Digital Experience and Distributed Agile software development.

The Software Peter principle is used in software engineering to describe a dying project which has become too complex to be understood even by its own developers.

<span class="mw-page-title-main">Continuous integration</span> Software development practice of building and testing frequenting

Continuous integration (CI) is the practice of frequently building and testing a software system during its development. It is intended to ensure that code written by programmers is always buildable, runnable and passes automated testing. Developers merge to an integration branch and an automated system builds and tests. Often, the automated process runs on each commit or runs on a schedule such as once a day.

Software rot is the deterioration of software quality or performance over time that leads to it becoming faulty, unusable, or needing upgrade.

William F. "Bill" Opdyke is an American computer scientist and enterprise architect at JPMorgan Chase, known for his early work on code refactoring.

In software development and other information technology fields, technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

NDepend is a static analysis tool for C# and .NET code to manage code quality and security. The tool proposes a large number of features, from CI/CD Web Reporting to Quality Gate and Dependencies Visualization. For that reason, the community refers to it as the "Swiss Army Knife" for .NET Developers.

Software archaeology or source code archeology is the study of poorly documented or undocumented legacy software implementations, as part of software maintenance. Software archaeology, named by analogy with archaeology, includes the reverse engineering of software modules, and the application of a variety of tools and processes for extracting and understanding program structure and recovering design information. Software archaeology may reveal dysfunctional team processes which have produced poorly designed or even unused software modules, and in some cases deliberately obfuscatory code may be found. The term has been in use for decades.

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organisational complexity.

<span class="mw-page-title-main">Extreme programming</span> Software development methodology

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

In computer programming, a design smell is a structure in a design that indicates a violation of fundamental design principles, and which can negatively impact the project's quality. The origin of the term can be traced to the term "code smell" which was featured in the book Refactoring: Improving the Design of Existing Code by Martin Fowler.

References

  1. 1 2 3 Tufano, Michele; Palomba, Fabio; Bavota, Gabriele; Oliveto, Rocco; Di Penta, Massimiliano; De Lucia, Andrea; Poshyvanyk, Denys (2015). "When and Why Your Code Starts to Smell Bad" (PDF). 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering. pp. 403–414. CiteSeerX   10.1.1.709.6783 . doi:10.1109/ICSE.2015.59. ISBN   978-1-4799-1934-5. S2CID   59100195.
  2. ↑ Fowler, Martin. "CodeSmell". martinfowler.com/. Retrieved 19 November 2014.
  3. 1 2 Beck, Kent. "Code Smells". WikiWikiWeb. Ward Cunningham. Retrieved 8 April 2020.
  4. ↑ Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code . Addison-Wesley. ISBN   978-0-201-48567-7.
  5. ↑ Binstock, Andrew (2011-06-27). "In Praise Of Small Code". Information Week. Retrieved 2011-06-27.
  6. ↑ Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN   978-0128013977.
  7. ↑ Martin, Robert C. (2009). "17: Smells and Heuristics". Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. ISBN   978-0-13-235088-4.
  8. ↑ Suryanarayana, Girish, Ganesh Samarthyam, and Tushar Sharma. Refactoring for Software Design Smells : Managing Technical Debt / Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma. 1st edition. Waltham, Massachusetts ; Morgan Kaufmann, 2015. Print.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.