{"id":1186,"date":"2024-01-18T23:20:51","date_gmt":"2024-01-18T15:20:51","guid":{"rendered":"https:\/\/www.fanyamin.com\/wordpress\/?p=1186"},"modified":"2024-01-18T23:21:42","modified_gmt":"2024-01-18T15:21:42","slug":"clean-code","status":"publish","type":"post","link":"https:\/\/www.fanyamin.com\/wordpress\/?p=1186","title":{"rendered":"Clean code"},"content":{"rendered":"<h1>overview<\/h1>\n<ul>\n<li>Clean code is obvious for other programmers.<\/li>\n<\/ul>\n<p>And I\u2019m not talking about super sophisticated algorithms. Poor variable naming, bloated classes and methods, magic numbers -you name it- all of that makes code sloppy and difficult to grasp.<\/p>\n<ul>\n<li>Clean code doesn\u2019t contain duplication.<\/li>\n<\/ul>\n<p>Each time you have to make a change in a duplicate code, you have to remember to make the same change to every instance. This increases the cognitive load and slows down the progress.<\/p>\n<ul>\n<li>Clean code contains a minimal number of classes and other moving parts.<\/li>\n<\/ul>\n<p>Less code is less stuff to keep in your head.<br \/>\nLess code is less maintenance.<br \/>\nLess code is fewer bugs.<br \/>\nCode is liability, keep it short and simple.<\/p>\n<ul>\n<li>Clean code passes all tests.<\/li>\n<\/ul>\n<p>You know your code is dirty when only 95% of your tests passed. You know you\u2019re screwed when your test coverage is 0%.<\/p>\n<ul>\n<li>Clean code is easier and cheaper to maintain!<\/li>\n<\/ul>\n<p>Code is clean if it can be understood easily \u2013 by everyone on the team.<br \/>\nClean code can be read and enhanced by a developer other than its original author.<br \/>\nWith understandability comes readability, changeability, extensibility and maintainability.<\/p>\n<hr \/>\n<h1>General rules<\/h1>\n<ol>\n<li>Follow standard conventions.<\/li>\n<li>Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.<\/li>\n<li>Boy scout rule. Leave the campground cleaner than you found it.<\/li>\n<li>Always find root cause. Always look for the root cause of a problem.<\/li>\n<\/ol>\n<h1>Design rules<\/h1>\n<ol>\n<li>Keep configurable data at high levels.<\/li>\n<li>Prefer polymorphism to if\/else or switch\/case.<\/li>\n<li>Separate multi-threading code.<\/li>\n<li>Prevent over-configurability.<\/li>\n<li>Use dependency injection.<\/li>\n<li>Follow Law of Demeter. A class should know only its direct dependencies.<\/li>\n<\/ol>\n<h1>Understandability tips<\/h1>\n<ol>\n<li>Be consistent. If you do something a certain way, do all similar things in the same way.<\/li>\n<li>Use explanatory variables.<\/li>\n<li>Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.<\/li>\n<li>Prefer dedicated value objects to primitive type.<\/li>\n<li>Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.<\/li>\n<li>Avoid negative conditionals.<\/li>\n<\/ol>\n<h1>Names rules<\/h1>\n<ol>\n<li>Choose descriptive and unambiguous names.<\/li>\n<li>Make meaningful distinction.<\/li>\n<li>Use pronounceable names.<\/li>\n<li>Use searchable names.<\/li>\n<li>Replace magic numbers with named constants.<\/li>\n<li>Avoid encodings. Don't append prefixes or type information.<\/li>\n<\/ol>\n<h1>Functions rules<\/h1>\n<ol>\n<li>Small.<\/li>\n<li>Do one thing.<\/li>\n<li>Use descriptive names.<\/li>\n<li>Prefer fewer arguments.<\/li>\n<li>Have no side effects.<\/li>\n<li>Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag.<\/li>\n<\/ol>\n<h1>Comments rules<\/h1>\n<ol>\n<li>Always try to explain yourself in code.<\/li>\n<li>Don't be redundant.<\/li>\n<li>Don't add obvious noise.<\/li>\n<li>Don't use closing brace comments.<\/li>\n<li>Don't comment out code. Just remove.<\/li>\n<li>Use as explanation of intent.<\/li>\n<li>Use as clarification of code.<\/li>\n<li>Use as warning of consequences.<\/li>\n<\/ol>\n<h1>Source code structure<\/h1>\n<ol>\n<li>Separate concepts vertically.<\/li>\n<li>Related code should appear vertically dense.<\/li>\n<li>Declare variables close to their usage.<\/li>\n<li>Dependent functions should be close.<\/li>\n<li>Similar functions should be close.<\/li>\n<li>Place functions in the downward direction.<\/li>\n<li>Keep lines short.<\/li>\n<li>Don't use horizontal alignment.<\/li>\n<li>Use white space to associate related things and disassociate weakly related.<\/li>\n<li>Don't break indentation.<\/li>\n<\/ol>\n<h1>Objects and data structures<\/h1>\n<ol>\n<li>Hide internal structure.<\/li>\n<li>Prefer data structures.<\/li>\n<li>Avoid hybrids structures (half object and half data).<\/li>\n<li>Should be small.<\/li>\n<li>Do one thing.<\/li>\n<li>Small number of instance variables.<\/li>\n<li>Base class should know nothing about their derivatives.<\/li>\n<li>Better to have many functions than to pass some code into a function to select a behavior.<\/li>\n<li>Prefer non-static methods to static methods.<\/li>\n<\/ol>\n<h1>Tests<\/h1>\n<ol>\n<li>One assert per test.<\/li>\n<li>Readable.<\/li>\n<li>Fast.<\/li>\n<li>Independent.<\/li>\n<li>Repeatable.<\/li>\n<\/ol>\n<h1>Code smells<\/h1>\n<ol>\n<li>Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.<\/li>\n<li>Fragility. The software breaks in many places due to a single change.<\/li>\n<li>Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.<\/li>\n<li>Needless Complexity.<\/li>\n<li>Needless Repetition.<\/li>\n<li>Opacity. The code is hard to understand.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>overview Clean code is obvious for other programmers. And I\u2019m not talking about super sophisticated algorithms. Poor variable naming, bloated classes and methods, magic numbers -you name it- all of that makes code sloppy and difficult to grasp. Clean code doesn\u2019t contain duplication. Each time you have to make a change in a duplicate code, [&hellip;] <a class=\"read-more\" href=\"https:\/\/www.fanyamin.com\/wordpress\/?p=1186\" title=\"Permanent Link to: Clean code\">&rarr;Read&nbsp;more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1186","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1186"}],"collection":[{"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1186"}],"version-history":[{"count":2,"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1186\/revisions"}],"predecessor-version":[{"id":1188,"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1186\/revisions\/1188"}],"wp:attachment":[{"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1186"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fanyamin.com\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}