{"id":77,"date":"2023-09-04T18:38:14","date_gmt":"2023-09-04T18:38:14","guid":{"rendered":"https:\/\/libraryresources.nse.org.ng\/setextbook\/chapter\/code-smells\/"},"modified":"2026-03-16T14:21:41","modified_gmt":"2026-03-16T14:21:41","slug":"code-smells","status":"publish","type":"chapter","link":"https:\/\/libraryresources.nse.org.ng\/setextbook\/chapter\/code-smells\/","title":{"raw":"Code Smells and Refactoring","rendered":"Code Smells and Refactoring"},"content":{"raw":"<div class=\"imgbleed bottom\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/CoverChapter09.png\"><img class=\"aligncenter size-full wp-image-76\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09.png\" alt=\"Chapter cover\" width=\"2550\" height=\"1320\"><\/a><\/div>\n<h2 class=\"chtitle\">Chapter 8\nCode Smells <span class=\"chtitlesmall\">and<\/span> Refactoring<\/h2>\n<div class=\"textbox textbox--sidebar\">If you want to learn more about any of the code smells and refactorings described in this chapter or want to know additional ways your code can smell, Martin (<span class=\"citation\">[pb_glossary id=\"701\"]2009[\/pb_glossary]<\/span>), <span class=\"citation\">[pb_glossary id=\"702\"]Shvets[\/pb_glossary]<\/span>, and Fowler and Beck (<span class=\"citation\">[pb_glossary id=\"700\"]2019[\/pb_glossary]<\/span>) are good resources.<\/div>\n[pb_glossary id=\"905\"]Code smells[\/pb_glossary] are indications that the code needs to be reorganized\u2014a sign your software is undergoing [pb_glossary id=\"906\"]code decay[\/pb_glossary]. Your code might need attention if you\u2019re having thoughts like these:\n<ul>\n \t<li>\u201cI would <strong>never show this code<\/strong> during an interview.\u201d<\/li>\n \t<li>\u201cI\u2019m going to <strong>start over<\/strong> and rewrite this code from scratch.\u201d<\/li>\n \t<li>\u201cEvery time I look at this code, I have to <strong>re-figure-out<\/strong> what it does.\u201d<\/li>\n \t<li>\u201cThese <strong>comments don\u2019t match the code <\/strong>. . .\u201d<\/li>\n \t<li>\u201cWhy is this <strong>code repeated<\/strong> in three different places?\u201d<\/li>\n \t<li>\u201cI want to switch out this component, but <strong>that\u2019ll break X, Y, and Z<\/strong> in this other place, and I don\u2019t want to deal with that.\u201d<\/li>\n<\/ul>\n<strong>Types of codes smells we\u2019ll cover<\/strong> (including how to fix them):\n<ul>\n \t<li>Code smells about <strong>comments<\/strong>.<\/li>\n \t<li>Code smells about <strong>functions<\/strong>.<\/li>\n \t<li><strong>General code<\/strong> smells (e.g., about the code within functions).<\/li>\n<\/ul>\n<h1>8.1 Why Care about Code Smells?<\/h1>\n<strong>Reasons<\/strong> to pay attention to and fix code smells:\n<ul>\n \t<li>Smelly code can be <strong>harder for you and others to maintain<\/strong> because the code is unclear. When code is hard to maintain, developers tend to work around it or re-create the same functionality elsewhere.<\/li>\n \t<li>Smelly code <strong>leads to smellier code<\/strong>. When you let your code become disorganized, you are giving yourself and others the message that smelly code is acceptable. Disorganized code also tends to give us an excuse to be lazy coders. A web development example: if you\u2019ve used CSS, you may have encountered frustrating situations where the style you\u2019re trying to apply is not working\u2014somewhere in the code (e.g., other CSS, HTML, or JS), your style is being overridden. Instead of tracking down the competing code or markup, you use the \u201c!important\u201d property, which forces the style to be applied. The codebase is a mess anyway, so who cares? Your future self.<\/li>\n \t<li>Smelly code builds up technical debt. If the code is working, there\u2019s never a reason to change it, right? Wrong. Each time you write sloppy code, you are contributing to your project\u2019s technical debt. Maybe it works now, but as sloppy software grows, it will get more difficult to deal with. That can mean your company needing to hire more developers to keep productivity up. Instead, productivity can go down because now the old developers are struggling to teach the new developers, and everyone is continuing to write sloppy code (Martin, <span class=\"citation\">[pb_glossary id=\"701\"]2009[\/pb_glossary]<\/span>). Ultimately, the software may have to be redeveloped entirely (which doesn\u2019t always solve the problem). Or the project could fail.<\/li>\n<\/ul>\n<h1>8.2 Your Code Stinks\u2014Now What?<\/h1>\nIf you can (e.g., your manager allows it), strongly consider [pb_glossary id=\"907\"]refactoring[\/pb_glossary]. Refactoring is when you improve your code without changing what the code does. Refactoring is a way to pay down technical debt.\n\nThe remainder of this chapter is about code smells and how to clean them up. This is not an exhaustive list. You can find more advice in the references at the end of the chapter.\n<h1>8.3 Comments<\/h1>\nWhen we first learned to code, many of us didn\u2019t write comments: solving problems and coding is fun; no time for boring comments! Then, we got more experience, started coding with others, were formally trained to code, or attempted to continue an old project, and we saw why comments are useful\u2014and then some of us jumped to the other extreme: too many comments. We explained functions with paragraphs of prose, or even commented each line. It\u2019s tedious, but it\u2019s the right thing to do, right? Unfortunately (and fortunately), <strong>too many comments can be as bad as none<\/strong>.\n<h2>8.3.1 Drawbacks of Having Many Comments<\/h2>\n<div class=\"textbox textbox--sidebar\">Don\u2019t fall into the trap of adding excessive comments to your code before an interview! Some prospective employers specifically look for over-commented code (or can\u2019t help but see it) as an indicator of poor programming habits.<\/div>\n<ul>\n \t<li>Comments <strong>get out of date quickly<\/strong>. If we update the code, then procrastinate on the comments, what we leave can be misleading (to others and our future selves). Also, more comments mean greater likelihood some will be ignored, giving us the smelly situation of some accurate and some inaccurate comments. In that case, why would we trust any of the comments?<\/li>\n \t<li>Writing comments for straightforward code <strong>can distract from the important comments<\/strong>. If the code was difficult to write, is long, is unique, is complex, or has a \u201cgotcha,\u201d comments can help call attention to idiosyncrasies of the code.<\/li>\n \t<li>Writing lots of comments could <strong>indicate the code needs to be simplified<\/strong>. Ideally, most of the code you write will be self-explanatory, so frequent comments are not needed.<\/li>\n<\/ul>\n<h2 class=\"page-break-before\">8.3.2 Code Smells about Comments<\/h2>\nBelow is a concise <strong>list of common code smells<\/strong> about comments and what to do about them (how to refactor).\n<ul>\n \t<li><strong>Obsolete Comment<\/strong> (no longer describes the code). Remove or update.\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n \t<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n \t<li><code><span class=\"green\">Uses the TwoFish block cipher with 256 bit key size<\/span><\/code><\/li>\n \t<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n \t<li><code>ThreeFish(512,data)<\/code><\/li>\n<\/ol>\n<\/li>\n \t<li><strong>Commented-Out Code<\/strong> (somebody thought they\u2019d need that code later, but the commented-out block is now getting out of date and in the way). Remove. If you\u2019re feeling risk-averse, save a backup or use a version-control system.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Commenting out code often comes with poor assumptions (e.g., you\u2019ll need the code later, others will understand why you commented it out, the surrounding code will continue having the same purpose, and so on).<\/div>\n<\/div>\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> updateWorldState():<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"green\">\"\"\"<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"green\">updateTime() # might need later<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"green\">updatePlayers()<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"green\">updatePoints()<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"green\">\"\"\"<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">for<\/span> p <span class=\"red\">in<\/span> players:<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 p.updateState()<\/code><\/li>\n<\/ol>\n<\/li>\n \t<li><strong>Redundant Comment<\/strong> (states what would already be immediately apparent to a programmer of any level). Remove. Less is more.\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n \t<li><code>getLength() <span class=\"green\"># gets the length<\/span><\/code><\/li>\n<\/ol>\n<\/li>\n \t<li><strong>Long Comment<\/strong> (multiple sentences, complicated, goes into a lot of detail). Simplify the code to make it more self-explanatory; shorten or remove comment.\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n \t<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n \t<li><code><span class=\"green\">This is the first function I made in this module, and it takes the user\u2019s Unicode text input, converts it to ASCII, then that creates a visualization of a typewriter typing the input. Problem is, as you might imagine, sometimes there\u2019s no good conversion to ASCII, so some meaning is lost.<\/span><\/code><\/li>\n \t<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<h1>8.4 Functions<\/h1>\n<div class=\"textbox textbox--sidebar\">If you\u2019re only writing a short program, does coding style matter? Treating code as disposable is a self-fulfilling prophecy.<\/div>\nA natural way to code is to start writing a function and then, as the program gets more complicated, keep adding to it. For example, if your program\u2019s GUI only has a start and a stop button, the function for populating the screen with UI elements only needs to draw those two buttons. Then, when you add a menu and a settings button, you could update the function to draw those elements, too. You then add user accounts and decide that function is a fine place to check if the user is logged in, their level of inactivity, show a pop-up about cool new features . . . and your function balloons. Understanding the small details of how the function works can even make one feel proud\u2014until the <strong>code becomes unmaintainable and bug-ridden<\/strong>.\n<h2>8.4.1 Code Smells about Functions<\/h2>\n<div class=\"textbox textbox--sidebar\">Software made of three to four line functions is amazing to behold!<\/div>\nFollow these <strong>refactoring suggestions<\/strong> to increase code readability, maintainability, and modularity.\n<ul>\n \t<li><strong>Long Function<\/strong> (more than 10 lines or so). Break into multiple functions. Aim for five lines or fewer.<\/li>\n \t<li><strong>Function with Many Jobs<\/strong> (doing more than what its name suggests, doing things that aren\u2019t closely related, doing many things). Break into multiple functions.\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> updateGUI():<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateTime()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateTimeDisplay()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateScores()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateScoreDisplay()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 refreshWindow()<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> updateState() :<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateTime()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateScores()<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> updateGUI():<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateTimeDisplay()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 updateScoreDisplay()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 refreshWindow()<\/code><\/li>\n<\/ol>\n<\/li>\n \t<li><strong>Function with Many Parameters<\/strong> (more than four, some say more than three). As appropriate, pass an object that combines the parameters, make calls within the function to get the parameter data, break into multiple functions, or find another way of reducing the number of parameters.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Zero function parameters is even better than four!<\/div>\n<\/div>\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n \t<li><code>initOutdoorPlace(floraList, faunaList, temperature, windSpeed, cloudiness, rockiness, birdNoises, grassLength)<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n \t<li><code>initOutdoorPlace(world1data)<\/code><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<h1>8.5 Code<\/h1>\nCode <strong>gets messy fast<\/strong> if you\u2019re not paying attention. One reason is because many of us weren\u2019t trained to be neat with code when we first learned it. To write tidy code, you may have to frequently <strong>stop and think<\/strong> about its design or be strict with yourself about <strong>refactoring regularly<\/strong>. Over time, you might adopt better habits.\n<h2 class=\"page-break-before\">8.5.1 Code Smells about Code in General<\/h2>\n<ul>\n \t<li><strong>Duplicate Code<\/strong> (same code in multiple places). Consolidate into one place, but watch out for creating unwanted dependencies.\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> updateLevelOfAlarm(npc):<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">if<\/span> (npc.isWalking() &amp;&amp; npc.isAlive() &amp;&amp;\u00a0 npc.isFriendly())<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(0)<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">else<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(500)<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 react(npc)<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> react(npc):<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">if<\/span> (npc.isWalking() &amp;&amp; npc.isAlive() &amp;&amp;\u00a0 npc.isFriendly())<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 keepWalking()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">else<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 runAway()<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> react(npc):<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">if<\/span> (npc.isHarmless())<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(0)<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 keepWalking()<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">else<\/span><\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(500)<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 \u00a0 \u00a0 runAway()<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> setLevelOfAlarm(level):<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 alarmLevel = level<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"red\">def<\/span> isHarmless(npc):<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 <span class=\"red\">return<\/span> (npc.isWalking() &amp;&amp; npc.isAlive() &amp;&amp; npc.isFriendly())<\/code><\/li>\n<\/ol>\n<\/li>\n \t<li><strong>Long Lines<\/strong> (more than 100 characters or so). Shorten by breaking into multiple lines, converting to a function call, defining new variables, and so on.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Thresholds like \u201c100 characters\u201d or \u201cfive lines\u201d are arbitrary. Generally, shorter is better, but not even that rule can be applied everywhere. For example, \u201csyntactic sugar\u201d is the term for concise and elegant code syntax, usually built into the programming language. It can make your code shorter, but what\u2019s the point if nobody can understand it!<\/div>\n<\/div>\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">if<\/span> (rectangle.coordinate[1][0] - rectangle.coordinate [2][0] &gt; 500 &amp;&amp; rectangle.coordinate[2][1] - rectangle.coordinate[3][1] &gt; 500 &amp;&amp; rectangle.isSquare()):<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">if<\/span> (rectangle.isSquare() &amp;&amp; rectangle.width &gt; 500):<\/code><\/li>\n<\/ol>\n<\/li>\n \t<li><strong>Inconsistent Conventions<\/strong> (formatting code differently in different places, or untidily). Follow whatever style conventions the code is already using. If it\u2019s a new project, plan to be self-consistent or follow accepted conventions for the language you\u2019re using.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">When adding to another person\u2019s code, it\u2019s best to follow their coding style conventions even if you prefer a different way. If their code style is sloppy and inconsistent, however, consider whether there\u2019s a polite way to fix the problem.<\/div>\n<\/div>\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">if<\/span> (whale.isSinging) {<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 activateAudioRecordingDevice();<\/code><\/li>\n \t<li><code>} <span class=\"red\">else<\/span> {<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 recording_device_off_confirmation_check();<\/code><\/li>\n \t<li><code>}<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"red\">if<\/span> (starfish.blockingCamera)<\/code><\/li>\n \t<li><code>{<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 AirCannon.Spray(camera.coordinates);<\/code><\/li>\n \t<li><code>}<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n \t<li><code><span class=\"red\">if<\/span> (Whale.isSinging) {<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 activateAudioRecordingDevice();<\/code><\/li>\n \t<li><code>} <span class=\"red\">else<\/span> {<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 confirmRecordingDeviceOff();<\/code><\/li>\n \t<li><code>}<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"red\">if<\/span> (Starfish.isBlockingCamera) {<\/code><\/li>\n \t<li><code>\u00a0 \u00a0 AirCannon.spray(Camera.coordinates);<\/code><\/li>\n \t<li><code>}<\/code><\/li>\n<\/ol>\n<\/li>\n \t<li><strong>Vague Naming<\/strong> (does not communicate what the function, variable, etc. is for). Rename it, even if the name is long. Long names can sometimes replace comments.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Wouldn\u2019t it be nice if code read like a book?<\/div>\n<\/div>\n<ol class=\"codestyle\">\n \t<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n \t<li><code>a = 100<\/code><\/li>\n \t<li><code>b = 2<\/code><\/li>\n \t<li><code><\/code><\/li>\n \t<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n \t<li><code>retail_price = 100<\/code><\/li>\n \t<li><code>wholesale_multiplier = 2<\/code><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<h1>8.6 Summary<\/h1>\nCleaning up your code can help make your software sustainable and extensible and can make your teammates happier, too.\n<ul>\n \t<li>Obsolete comment? Remove or update.<\/li>\n \t<li>Commented-out code? Remove.<\/li>\n \t<li>Redundant comment? Remove.<\/li>\n \t<li>Long comment? Simplify, shorten, or remove.<\/li>\n \t<li>Long function (more than ~10 lines)? Split.<\/li>\n \t<li>Function with many jobs? Split.<\/li>\n \t<li>Function with many parameters? Pass an object, make calls to get the parameter data, or split.<\/li>\n \t<li>Duplicate code? Consolidate.<\/li>\n \t<li>Long lines (more than ~100 characters)? Shorten, convert to function, or define new variables.<\/li>\n \t<li>Inconsistent conventions? Follow existing conventions.<\/li>\n \t<li>Vague naming? Rename.<\/li>\n<\/ul>\n<h1>References<\/h1>\n<p class=\"hanging-indent\">Fowler, M., &amp; Beck, K. (2019). <em>Refactoring: Improving the design of existing code<\/em>. Addison-Wesley.<\/p>\n<p class=\"hanging-indent\">Martin, R. C. (2009). <em>Clean code: A handbook of Agile Software craftsmanship<\/em>. Prentice Hall.<\/p>\n<p class=\"hanging-indent\">Shvets, A. (n.d.). <em>Refactoring and Design Patterns<\/em>. <a href=\"https:\/\/refactoring.guru\/\">https:\/\/refactoring.guru\/<\/a><\/p>","rendered":"<div class=\"imgbleed bottom\"><a href=\"https:\/\/open.oregonstate.education\/app\/uploads\/sites\/174\/2023\/09\/CoverChapter09.png\"><img decoding=\"async\" class=\"aligncenter size-full wp-image-76\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09.png\" alt=\"Chapter cover\" width=\"2550\" height=\"1320\" srcset=\"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09.png 2550w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-300x155.png 300w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-1024x530.png 1024w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-768x398.png 768w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-1536x795.png 1536w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-2048x1060.png 2048w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-65x34.png 65w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-225x116.png 225w, https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-content\/uploads\/sites\/16\/2023\/09\/CoverChapter09-350x181.png 350w\" sizes=\"(max-width: 2550px) 100vw, 2550px\" \/><\/a><\/div>\n<h2 class=\"chtitle\">Chapter 8<br \/>\nCode Smells <span class=\"chtitlesmall\">and<\/span> Refactoring<\/h2>\n<div class=\"textbox textbox--sidebar\">If you want to learn more about any of the code smells and refactorings described in this chapter or want to know additional ways your code can smell, Martin (<span class=\"citation\">2009<\/span>), <span class=\"citation\">Shvets<\/span>, and Fowler and Beck (<span class=\"citation\">2019<\/span>) are good resources.<\/div>\n<p>Code smells are indications that the code needs to be reorganized\u2014a sign your software is undergoing code decay. Your code might need attention if you\u2019re having thoughts like these:<\/p>\n<ul>\n<li>\u201cI would <strong>never show this code<\/strong> during an interview.\u201d<\/li>\n<li>\u201cI\u2019m going to <strong>start over<\/strong> and rewrite this code from scratch.\u201d<\/li>\n<li>\u201cEvery time I look at this code, I have to <strong>re-figure-out<\/strong> what it does.\u201d<\/li>\n<li>\u201cThese <strong>comments don\u2019t match the code <\/strong>. . .\u201d<\/li>\n<li>\u201cWhy is this <strong>code repeated<\/strong> in three different places?\u201d<\/li>\n<li>\u201cI want to switch out this component, but <strong>that\u2019ll break X, Y, and Z<\/strong> in this other place, and I don\u2019t want to deal with that.\u201d<\/li>\n<\/ul>\n<p><strong>Types of codes smells we\u2019ll cover<\/strong> (including how to fix them):<\/p>\n<ul>\n<li>Code smells about <strong>comments<\/strong>.<\/li>\n<li>Code smells about <strong>functions<\/strong>.<\/li>\n<li><strong>General code<\/strong> smells (e.g., about the code within functions).<\/li>\n<\/ul>\n<h1>8.1 Why Care about Code Smells?<\/h1>\n<p><strong>Reasons<\/strong> to pay attention to and fix code smells:<\/p>\n<ul>\n<li>Smelly code can be <strong>harder for you and others to maintain<\/strong> because the code is unclear. When code is hard to maintain, developers tend to work around it or re-create the same functionality elsewhere.<\/li>\n<li>Smelly code <strong>leads to smellier code<\/strong>. When you let your code become disorganized, you are giving yourself and others the message that smelly code is acceptable. Disorganized code also tends to give us an excuse to be lazy coders. A web development example: if you\u2019ve used CSS, you may have encountered frustrating situations where the style you\u2019re trying to apply is not working\u2014somewhere in the code (e.g., other CSS, HTML, or JS), your style is being overridden. Instead of tracking down the competing code or markup, you use the \u201c!important\u201d property, which forces the style to be applied. The codebase is a mess anyway, so who cares? Your future self.<\/li>\n<li>Smelly code builds up technical debt. If the code is working, there\u2019s never a reason to change it, right? Wrong. Each time you write sloppy code, you are contributing to your project\u2019s technical debt. Maybe it works now, but as sloppy software grows, it will get more difficult to deal with. That can mean your company needing to hire more developers to keep productivity up. Instead, productivity can go down because now the old developers are struggling to teach the new developers, and everyone is continuing to write sloppy code (Martin, <span class=\"citation\">2009<\/span>). Ultimately, the software may have to be redeveloped entirely (which doesn\u2019t always solve the problem). Or the project could fail.<\/li>\n<\/ul>\n<h1>8.2 Your Code Stinks\u2014Now What?<\/h1>\n<p>If you can (e.g., your manager allows it), strongly consider refactoring. Refactoring is when you improve your code without changing what the code does. Refactoring is a way to pay down technical debt.<\/p>\n<p>The remainder of this chapter is about code smells and how to clean them up. This is not an exhaustive list. You can find more advice in the references at the end of the chapter.<\/p>\n<h1>8.3 Comments<\/h1>\n<p>When we first learned to code, many of us didn\u2019t write comments: solving problems and coding is fun; no time for boring comments! Then, we got more experience, started coding with others, were formally trained to code, or attempted to continue an old project, and we saw why comments are useful\u2014and then some of us jumped to the other extreme: too many comments. We explained functions with paragraphs of prose, or even commented each line. It\u2019s tedious, but it\u2019s the right thing to do, right? Unfortunately (and fortunately), <strong>too many comments can be as bad as none<\/strong>.<\/p>\n<h2>8.3.1 Drawbacks of Having Many Comments<\/h2>\n<div class=\"textbox textbox--sidebar\">Don\u2019t fall into the trap of adding excessive comments to your code before an interview! Some prospective employers specifically look for over-commented code (or can\u2019t help but see it) as an indicator of poor programming habits.<\/div>\n<ul>\n<li>Comments <strong>get out of date quickly<\/strong>. If we update the code, then procrastinate on the comments, what we leave can be misleading (to others and our future selves). Also, more comments mean greater likelihood some will be ignored, giving us the smelly situation of some accurate and some inaccurate comments. In that case, why would we trust any of the comments?<\/li>\n<li>Writing comments for straightforward code <strong>can distract from the important comments<\/strong>. If the code was difficult to write, is long, is unique, is complex, or has a \u201cgotcha,\u201d comments can help call attention to idiosyncrasies of the code.<\/li>\n<li>Writing lots of comments could <strong>indicate the code needs to be simplified<\/strong>. Ideally, most of the code you write will be self-explanatory, so frequent comments are not needed.<\/li>\n<\/ul>\n<h2 class=\"page-break-before\">8.3.2 Code Smells about Comments<\/h2>\n<p>Below is a concise <strong>list of common code smells<\/strong> about comments and what to do about them (how to refactor).<\/p>\n<ul>\n<li><strong>Obsolete Comment<\/strong> (no longer describes the code). Remove or update.\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n<li><code><span class=\"green\">Uses the TwoFish block cipher with 256 bit key size<\/span><\/code><\/li>\n<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n<li><code>ThreeFish(512,data)<\/code><\/li>\n<\/ol>\n<\/li>\n<li><strong>Commented-Out Code<\/strong> (somebody thought they\u2019d need that code later, but the commented-out block is now getting out of date and in the way). Remove. If you\u2019re feeling risk-averse, save a backup or use a version-control system.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Commenting out code often comes with poor assumptions (e.g., you\u2019ll need the code later, others will understand why you commented it out, the surrounding code will continue having the same purpose, and so on).<\/div>\n<\/div>\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> updateWorldState():<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"green\">\"\"\"<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"green\">updateTime() # might need later<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"green\">updatePlayers()<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"green\">updatePoints()<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"green\">\"\"\"<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">for<\/span> p <span class=\"red\">in<\/span> players:<\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 p.updateState()<\/code><\/li>\n<\/ol>\n<\/li>\n<li><strong>Redundant Comment<\/strong> (states what would already be immediately apparent to a programmer of any level). Remove. Less is more.\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n<li><code>getLength() <span class=\"green\"># gets the length<\/span><\/code><\/li>\n<\/ol>\n<\/li>\n<li><strong>Long Comment<\/strong> (multiple sentences, complicated, goes into a lot of detail). Simplify the code to make it more self-explanatory; shorten or remove comment.\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># SMELLY<\/span><\/code><\/li>\n<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n<li><code><span class=\"green\">This is the first function I made in this module, and it takes the user\u2019s Unicode text input, converts it to ASCII, then that creates a visualization of a typewriter typing the input. Problem is, as you might imagine, sometimes there\u2019s no good conversion to ASCII, so some meaning is lost.<\/span><\/code><\/li>\n<li><code><span class=\"green\">\"\"\"<\/span><\/code><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<h1>8.4 Functions<\/h1>\n<div class=\"textbox textbox--sidebar\">If you\u2019re only writing a short program, does coding style matter? Treating code as disposable is a self-fulfilling prophecy.<\/div>\n<p>A natural way to code is to start writing a function and then, as the program gets more complicated, keep adding to it. For example, if your program\u2019s GUI only has a start and a stop button, the function for populating the screen with UI elements only needs to draw those two buttons. Then, when you add a menu and a settings button, you could update the function to draw those elements, too. You then add user accounts and decide that function is a fine place to check if the user is logged in, their level of inactivity, show a pop-up about cool new features . . . and your function balloons. Understanding the small details of how the function works can even make one feel proud\u2014until the <strong>code becomes unmaintainable and bug-ridden<\/strong>.<\/p>\n<h2>8.4.1 Code Smells about Functions<\/h2>\n<div class=\"textbox textbox--sidebar\">Software made of three to four line functions is amazing to behold!<\/div>\n<p>Follow these <strong>refactoring suggestions<\/strong> to increase code readability, maintainability, and modularity.<\/p>\n<ul>\n<li><strong>Long Function<\/strong> (more than 10 lines or so). Break into multiple functions. Aim for five lines or fewer.<\/li>\n<li><strong>Function with Many Jobs<\/strong> (doing more than what its name suggests, doing things that aren\u2019t closely related, doing many things). Break into multiple functions.\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> updateGUI():<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateTime()<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateTimeDisplay()<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateScores()<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateScoreDisplay()<\/code><\/li>\n<li><code>\u00a0 \u00a0 refreshWindow()<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> updateState() :<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateTime()<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateScores()<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> updateGUI():<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateTimeDisplay()<\/code><\/li>\n<li><code>\u00a0 \u00a0 updateScoreDisplay()<\/code><\/li>\n<li><code>\u00a0 \u00a0 refreshWindow()<\/code><\/li>\n<\/ol>\n<\/li>\n<li><strong>Function with Many Parameters<\/strong> (more than four, some say more than three). As appropriate, pass an object that combines the parameters, make calls within the function to get the parameter data, break into multiple functions, or find another way of reducing the number of parameters.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Zero function parameters is even better than four!<\/div>\n<\/div>\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n<li><code>initOutdoorPlace(floraList, faunaList, temperature, windSpeed, cloudiness, rockiness, birdNoises, grassLength)<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n<li><code>initOutdoorPlace(world1data)<\/code><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<h1>8.5 Code<\/h1>\n<p>Code <strong>gets messy fast<\/strong> if you\u2019re not paying attention. One reason is because many of us weren\u2019t trained to be neat with code when we first learned it. To write tidy code, you may have to frequently <strong>stop and think<\/strong> about its design or be strict with yourself about <strong>refactoring regularly<\/strong>. Over time, you might adopt better habits.<\/p>\n<h2 class=\"page-break-before\">8.5.1 Code Smells about Code in General<\/h2>\n<ul>\n<li><strong>Duplicate Code<\/strong> (same code in multiple places). Consolidate into one place, but watch out for creating unwanted dependencies.\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> updateLevelOfAlarm(npc):<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">if<\/span> (npc.isWalking() &amp;&amp; npc.isAlive() &amp;&amp;\u00a0 npc.isFriendly())<\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(0)<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">else<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(500)<\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 react(npc)<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> react(npc):<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">if<\/span> (npc.isWalking() &amp;&amp; npc.isAlive() &amp;&amp;\u00a0 npc.isFriendly())<\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 keepWalking()<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">else<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 runAway()<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> react(npc):<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">if<\/span> (npc.isHarmless())<\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(0)<\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 keepWalking()<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">else<\/span><\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 setLevelOfAlarm(500)<\/code><\/li>\n<li><code>\u00a0 \u00a0 \u00a0 \u00a0 runAway()<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> setLevelOfAlarm(level):<\/code><\/li>\n<li><code>\u00a0 \u00a0 alarmLevel = level<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"red\">def<\/span> isHarmless(npc):<\/code><\/li>\n<li><code>\u00a0 \u00a0 <span class=\"red\">return<\/span> (npc.isWalking() &amp;&amp; npc.isAlive() &amp;&amp; npc.isFriendly())<\/code><\/li>\n<\/ol>\n<\/li>\n<li><strong>Long Lines<\/strong> (more than 100 characters or so). Shorten by breaking into multiple lines, converting to a function call, defining new variables, and so on.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Thresholds like \u201c100 characters\u201d or \u201cfive lines\u201d are arbitrary. Generally, shorter is better, but not even that rule can be applied everywhere. For example, \u201csyntactic sugar\u201d is the term for concise and elegant code syntax, usually built into the programming language. It can make your code shorter, but what\u2019s the point if nobody can understand it!<\/div>\n<\/div>\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n<li><code><span class=\"red\">if<\/span> (rectangle.coordinate[1][0] - rectangle.coordinate [2][0] &gt; 500 &amp;&amp; rectangle.coordinate[2][1] - rectangle.coordinate[3][1] &gt; 500 &amp;&amp; rectangle.isSquare()):<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n<li><code><span class=\"red\">if<\/span> (rectangle.isSquare() &amp;&amp; rectangle.width &gt; 500):<\/code><\/li>\n<\/ol>\n<\/li>\n<li><strong>Inconsistent Conventions<\/strong> (formatting code differently in different places, or untidily). Follow whatever style conventions the code is already using. If it\u2019s a new project, plan to be self-consistent or follow accepted conventions for the language you\u2019re using.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">When adding to another person\u2019s code, it\u2019s best to follow their coding style conventions even if you prefer a different way. If their code style is sloppy and inconsistent, however, consider whether there\u2019s a polite way to fix the problem.<\/div>\n<\/div>\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n<li><code><span class=\"red\">if<\/span> (whale.isSinging) {<\/code><\/li>\n<li><code>\u00a0 \u00a0 activateAudioRecordingDevice();<\/code><\/li>\n<li><code>} <span class=\"red\">else<\/span> {<\/code><\/li>\n<li><code>\u00a0 \u00a0 recording_device_off_confirmation_check();<\/code><\/li>\n<li><code>}<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"red\">if<\/span> (starfish.blockingCamera)<\/code><\/li>\n<li><code>{<\/code><\/li>\n<li><code>\u00a0 \u00a0 AirCannon.Spray(camera.coordinates);<\/code><\/li>\n<li><code>}<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n<li><code><span class=\"red\">if<\/span> (Whale.isSinging) {<\/code><\/li>\n<li><code>\u00a0 \u00a0 activateAudioRecordingDevice();<\/code><\/li>\n<li><code>} <span class=\"red\">else<\/span> {<\/code><\/li>\n<li><code>\u00a0 \u00a0 confirmRecordingDeviceOff();<\/code><\/li>\n<li><code>}<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"red\">if<\/span> (Starfish.isBlockingCamera) {<\/code><\/li>\n<li><code>\u00a0 \u00a0 AirCannon.spray(Camera.coordinates);<\/code><\/li>\n<li><code>}<\/code><\/li>\n<\/ol>\n<\/li>\n<li><strong>Vague Naming<\/strong> (does not communicate what the function, variable, etc. is for). Rename it, even if the name is long. Long names can sometimes replace comments.\n<div class=\"smallcontainer\">\n<div class=\"textbox textbox--sidebar\">Wouldn\u2019t it be nice if code read like a book?<\/div>\n<\/div>\n<ol class=\"codestyle\">\n<li><code><span class=\"green\"># BEFORE<\/span><\/code><\/li>\n<li><code>a = 100<\/code><\/li>\n<li><code>b = 2<\/code><\/li>\n<li><code><\/code><\/li>\n<li><code><span class=\"green\"># AFTER<\/span><\/code><\/li>\n<li><code>retail_price = 100<\/code><\/li>\n<li><code>wholesale_multiplier = 2<\/code><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<h1>8.6 Summary<\/h1>\n<p>Cleaning up your code can help make your software sustainable and extensible and can make your teammates happier, too.<\/p>\n<ul>\n<li>Obsolete comment? Remove or update.<\/li>\n<li>Commented-out code? Remove.<\/li>\n<li>Redundant comment? Remove.<\/li>\n<li>Long comment? Simplify, shorten, or remove.<\/li>\n<li>Long function (more than ~10 lines)? Split.<\/li>\n<li>Function with many jobs? Split.<\/li>\n<li>Function with many parameters? Pass an object, make calls to get the parameter data, or split.<\/li>\n<li>Duplicate code? Consolidate.<\/li>\n<li>Long lines (more than ~100 characters)? Shorten, convert to function, or define new variables.<\/li>\n<li>Inconsistent conventions? Follow existing conventions.<\/li>\n<li>Vague naming? Rename.<\/li>\n<\/ul>\n<h1>References<\/h1>\n<p class=\"hanging-indent\">Fowler, M., &amp; Beck, K. (2019). <em>Refactoring: Improving the design of existing code<\/em>. Addison-Wesley.<\/p>\n<p class=\"hanging-indent\">Martin, R. C. (2009). <em>Clean code: A handbook of Agile Software craftsmanship<\/em>. Prentice Hall.<\/p>\n<p class=\"hanging-indent\">Shvets, A. (n.d.). <em>Refactoring and Design Patterns<\/em>. <a href=\"https:\/\/refactoring.guru\/\">https:\/\/refactoring.guru\/<\/a><\/p>\n<div class=\"glossary\"><span class=\"screen-reader-text\" id=\"definition\">definition<\/span><template id=\"term_77_701\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_77_701\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_77_702\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_77_702\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_77_700\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_77_700\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_77_905\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_77_905\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_77_906\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_77_906\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_77_907\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_77_907\"><div tabindex=\"-1\"><\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><\/div>","protected":false},"author":1,"menu_order":8,"template":"","meta":{"pb_show_title":"","pb_short_title":"Code Smells","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[48],"contributor":[],"license":[],"class_list":["post-77","chapter","type-chapter","status-publish","hentry","chapter-type-standard"],"part":19,"_links":{"self":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/77","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":1,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/77\/revisions"}],"predecessor-version":[{"id":78,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/77\/revisions\/78"}],"part":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/parts\/19"}],"metadata":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapters\/77\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/media?parent=77"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/pressbooks\/v2\/chapter-type?post=77"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/contributor?post=77"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/setextbook\/wp-json\/wp\/v2\/license?post=77"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}