CCD-Poster-A2

The Clean Code Developer Initiative was initiated by Stefan Lieser and Ralph Westphal early in 2009. Largely inspired by the Book Clean Code — a Handbook of Agile Software Craftsmanship by Robert C. Martin, the Initiative aims at growing an attitude of professionalism amongst software developers. It is rooted in the Software Craftsmanship and Agile Movement. As a help for understanding and practicing, the Clean Code Developer Initiative grouped these into five levels or degrees (in allusion to martial arts training).

The Path to Clean Code

  • Build for Change
  • Care for Correctness
  • Work efficiently
  • Rethink your actions

Red Path — understanding

Principles

DRY — Don’t Repeat Yourself

Don’t bore your readers by stating the same again and again — build viable abstractions instead. Avoid duplicated functionality, remove unnecessary data redundancy, automate repetitive tasks. Sonar source has an interesting duplicate code detector build in.

KISS — Keep it simple, stupid

“Everything should be made as simple as possible, but not simpler” (Einstein). Write code foremost to be understandable. Resist using an interesting solution, when there also is a straight forward (albeit boring) standard solution.

Avoid Preliminary Optimization

Distrust your own cleverness. “More computing sins are committed in the name of efficiency than for any other single reason – including blind stupidity” (W.A.Wulf). Defer improvements “for later”. Require an objective proof for performance problems, based on real-world data. It is always easier and better to profile later your code on a proven architecture and readable code than the other way around! Moreover locally premature optimization lead most of the time to difficult to read and duplicated code: e.g. writing N cache instead of seeing later in profiler that you may need one at many place in your architecture for a lot of different abstractions.

FCoI —Favor Composition over Inheritance

Build up functionality from self-contained abstractions, instead of cleverly extending, bending or specializing. Avoid proliferation of special cases. Inheritance make sometimes code more fragile, and in presence of bad API force you to write code you don’t need to override behaviors.

Practices

Boy Scout Rule

Whenever you enter some area, leave it in somewhat better shape than you found it. If everyone on the team is doing this, they make small regular contributions to code base health every day.

Root Cause Analysis

Never do “programming by coincidence”. Try to understand why something works or breaks. Never act based on assumptions. Don’t treat symptoms. Better don’t act unless you understand.

Use Version Management

Use a revision control system. Create thematically consistent change sets, write small and clear commit messages, learn to handle branching and merging. Do yourself a favor and use nothing else than GIT for now: its speed, branching make it a joy to use compare to any other revision system.

Simple Refactoring

Controllable process improving your code without writing new functionality. see https://refactoring.guru/catalog

Reflection

Review your own achievements based on the principles (especially but not limited to those you’re focusing on currently). Partition your work into tasks which can be finished on one day. Take the time to reflect.

Orange Path — sharpening

Principles

SLA — Single Level of Abstraction

Each piece of code should talk on a distinctive level of granularity. Don’t mix implementation details with invocation of high-level abstractions. Refactor code to balance the level of abstraction. All statements of a method should belong to the same level of abstraction. If there is a statement which belongs to a lower level of abstraction, it should go to a private method which comprises statements on this level. Stated in Clean Code (page 36)

SRP — Single Responsibility Principle

Every class or entity should deal with one topic solely, and do that well. What needs to be said for a given concern, should be found at a single location.

SoC — Separation of Concerns

Decompose functionality into orthogonal concerns. Increase focusing and cohesion within a single concern, and decrease coupling amongst separate concerns.

Source Code Conventions

Establish writing conventions based on readability. Code is more often read than written. Reason about the purpose of conventions, then stick to them. Especially focus on naming conventions and correct source code comments. Comments should not detail what you do, but the purpose why you do it.

Practices

Issue Tracking

Capture problems and work items as well delineated issues. Track them in a structured way, establish ubiquitous procedures for assigning and resolving issues.

Automate Tests

Verify correct integration of the parts by running tests automatically. Build a safety net allowing to perform refactoring while retaining correct operation. There is a lot of frameworks in JAVA: TestNG, Junit, JBehave, Mockito and HamCrest are all worth using!

Eager Reading

Acquire an attitude of concern for the ongoing evolution of the coding craft. Read books, journals and blogs (Java DZone). Learn a new programming language every year.

Code Reviews

Four eyes are better then two. Present and explain your code to other programmers. Establish practices like code reviews and pair programming.

Yellow Path — segregating

Principles

ISP — Interface Segregation Principle

Keep interfaces focused and confined to a set of operations likely to be used in conjunction. Avoid to tie clients to the details of a service implementation. Keep interface also small to not force people to implement too much methods.

Dependency Inversion

revert dependencies with respect to the naïve logical meaning. Instead of implementing high-level functions through low-level functions, turn the latter into services and thus make both depend on interfaces.

Liskov Substitution Principle

The Liskov Substitution Principle (LSP, lsp) is a concept in Object Oriented Programming that states: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Rule of Least Surprise

every piece of code should behave exactly in the way obvious from the names, the concepts and the general context. The reader should be able to get the essence of what’s going on already from the first coarse-grained view.

Information Hiding

every part — be it function, object, interface or subsystem — should expose only the bare minimum required to use it effectively.

Practices

Automated Unit Tests

Cover individual components with tests in isolation. Break the reasoning in terms of contracts down to the implementation level

Mockups

Build mock-ups, dummies, stubs and fakes to create a controlled environment for reasoning and test. Balsamiq is great and not expensive.

Code Coverage

Base your reasoning and testing on coverage analysis (instructions, branches, decisions).

Advanced Refactoring

Apply the more advanced types of refactoring techniques to rearrange and restructure code fluently. Ensure correctness through your stock of unit tests.

Community Participation

Participate actively, beyond the local team. Report bugs, provide test cases, work with library developers, visit local user groups, participate in conferences.

Green Path — decoupling

Principles

OCP — Open Closed Principle

any class or functional unit should be open towards extensions, but closed against modifications. Extending it should not require changing the internals, nor tie the extension to these internals. Increase cohesion, decrease coupling.

Tell, don’t ask

invoke services instead of doing things yourselves. Don’t inspect state and operate from the outside. You should instead tell an object what to do.

Law of Demeter

don’t write “train wreck code”. Talk to direct collaborators only. Within each scope, confine yourself to using the parameters, local methods, locally created objects, associated partners and global services.

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. The guideline was proposed at Northeastern University^towards the end of 1987, and can be succinctly summarized in each of the following ways:

  • Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
  • Each unit should only talk to its friends; don't talk to strangers.
  • Only talk to your immediate friends.

Practices

Continuous Integration

Integrate changes timely and frequently. Perform this integration process automatically, in a controlled and reproducible environment, perform the unit and integration test suites as part of this process. Recommended software are Atlassian Bamboo, JetBrains Teamcity, Apache Hudson.

Inversion of Control Container

Use Dependency Injection to implement IoC (e.g. Spring MVC). Use service locators, employ the DI patterns or use an existing DI container implementation or framework.

Code Metrics

Use static analysis and similar quantitative measurements to monitor various aspects of a source base. I use PMD source code analyzer and FindBugs in Sonar Source or as plugin Eclipse and IntelliJ

Quality Measurements

Observe instead of assuming. Monitor the code quality, measure performance, observe defect rates. Estimate efforts and verify your guesses after the fact. Identify impediments.

Learn by Teaching

Share your experience and knowledge. Explaining something is the best way to understand it yourself.

Blue Path — balancing

Principles

Segregate Design and Implementation

Clearly delineate planning and doing. Design must not duplicate implementation work, and implementation concerns must not interfere with architectural considerations. Otherwise implementation will supersede the design and the real system will end in chaos.

Implementation reflects Design

Code in accordance with design. Traces of architecture should be visible down into individual implementation structures, names, organization of the code base and the runtime structure. Never play tricks to undermine and thwart the design and create a second reality.

YAGNI — You Ain’t Gonna Need It

Decide later and don’t do it, if in doubt. Question your own brilliant ideas — write them down, but defer implementation for later, because, well, you ain’t gonna need that crap. Don’t say “I can do that on a single afternoon” — be prudent: doing it seriously will be a major undertaking. Refrain from spending effort without a reason.

Practices

Continuous Delivery

Extend the automated continuous integration into deployment and setup. Plan and test the steps towards an release, and finally automate them. Create a platform to roll out development snapshots, integration builds, release candidates and service updates.

Iterative Development

Development is a learning process. Instead of achieving perfection through a single big bang, proceed in incremental steps and include feedback from the user or customer. Use each iteration for a retrospective and adjust your procedures.

Components and Contracts

Employ the thinking in terms of components and contracts from the largest to the smallest. Each component establishes some kind of isolation, which helps to cut down complexity.

Test first

Also known as Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. Practice and improve your skills by doing some TDD Kata 1Kata 2Kata 3&160;

Start from the usage situation. Each unit, class, component or subsystem has clients. Instead of detached planning, or worse, guessing what might be cool, work out the requirements and contract from an exemplary use in code. Transform this into a test before you even think about how to make it work.

comments powered by Disqus

You might like also

systematization of knowledge within major blockchain protocols or consensus
Alexis Gauba presented a systematization of knowledge within major blockchain protocols or consensus, addresses the common challenges, economic model and solutions and provides a formal structure within which to compare them in this keynote presentation at Hyperledger Global Forum. …
7 Days ago
Stablecoins: Crypto's Holy Grail or Fools’ Errand? by Dr Garrick Hileman
I was attending the interesting LECTURE "Stablecoins: Crypto's Holy Grail or Fools’ Errand?" by Dr Garrick Hileman - Head of reseach at Blockchain - London School of Economics - United Kingdom at hashtagETH hashtagZurich and here is a copy of the slides Introducing: 2019 State of Stablecoins The 2019 report builds on its predecessor to provide an updated and expanded look at the current state of the stablecoin market - a space where we expect to see significant innovation in …
7 Days ago
The State of Stablecoins 2019: Hype vs. Reality in the Race for Stable, Global, Digital Money
The report, entitled “The State of Stablecoins 2019: Hype vs. Reality in the Race for Stable, Global, Digital Money” is based on information collected from 40 crypto and stablecoin firms. The report’s lead author is George Samman, a blockchain and cryptocurrency advisor. According to the document, Samman “was commissioned to research the stablecoin landscape and then independently report his findings for the broader industry to learn from.” https://bit.ly/2TWc1ao      …
7 Days ago
ICO STATISTICS FOR 2018 AND OUTLOOK FOR 2019
The last 6 months of ICO have been imported and can be browse at https://ico.tokens-economy.com/statistics. I display there historical ICO data for all cryptocurrencies friendly countries for each month of the year. What you can get out of all these charts: You can see the number of ICO per months over 13 major countries (Cayman-Islands, UK, USA, Cyprus, Estonia, France, Germany, Liechtenstein, Malta, Russia, Singapore, Slovenia, Switzerland), Each country has its own color, how often that color appear on the map represents the …
7 Days ago
MAJOR BLOCKCHAIN CONSENSUS ALGORITHMS AS AN INFOGRAPHICS
Consensus algorithms enable network participants to agree on the contents of a blockchain in a distributed and trust-less manner. I’ve listed in the past few months all of them at tokens-economy.gitbook.io/consensus/ and thought it will be cool also to produce an Infographics The PNG (4528 x 2894 px, 2.5MB) can be downloaded here and the PDF version (280kb) with clickable consensus links here …
7 Days ago
No Thumbnail was found
Usually, a percentage of the tokens is sold to ICO participants and a percentage kept for the company’s needs. The token distribution and allocation of the token is usually a chapter in the future company whitepaper. A pie chart displays how and to whom tokens will be allocated. But how much tokens are allocated (amount) and what are they used for? how much token should I spend for advisor? is 15% of all tokens too much for founder? How many …
199 Days ago
No Thumbnail was found
introduction This is my attempt to list all possible blockchain consensus out there, I welcome pull request of the blockchain community! let's make it the main reference for blockchain consensus. Visit also Tokens-Economy.com to keep track of new developments in the distributed ledger technology space. Blockchain Consensus? At the core of the Blockchain disruption is a consensus algorithm: Consensus algorithms enable network participants to agree on the contents of a blockchain in a distributed and trust-less manner. “Consensus decision-making is a group …
210 Days ago
Initial Coin Offering security checklist
Blockchain technology and cryptocurrencies have revolutionized the way companies raise capital but at the same time are bringing their own sets of challenges. To ensure that your startup will go through that (ad)venture in a safe manner, you should always adhere to best security practices, for your company AND your investors.  This mind map will present you in a visual way lots of valuable information like: A compilation of the most dangerous threats to the ICO industry and how to mitigate, …
231 Days ago
Initial Coin Offering in most relevant countries
 This new rendering will allow you to better compare countries The rendering being dynamic you can also pass some parameters like https://ico.tokens-economy.com/statistics/collage.html?width=800&height=800 The default size is width=450&height=450 Filter by year ico end. e.g all ico ended in 2017 https://ico.tokens-economy.com/statistics/collage.html?year=2017  Filter by category and year https://ico.tokens-economy.com/statistics/collage.html?category=Cryptocurrency  And more ICO with no raised amount is also displayed now. ICO webpage has been added Text in bubble scale now properly and are always centered     …
245 Days ago
2751 coins, 47 Consensus and 82 cryptographic algorithms
The innovation speed in Blockchain landscape is just breathtaking and being able to (or to be honest trying to...) follow all these rapid changes is a chance for all software engineers. At the core of the Blockchain disruption are consensus algorithm: Consensus algorithms enable network participants to agree on the contents of a blockchain in a distributed and trust-less manner. And the consensus algorithm plays a crucial role in maintaining the safety and efficiency of blockchain. Using the right algorithm may bring a significant increase to the …
253 Days ago