# A code smell catalogue you can clone and refactor under test > CodelyTV's repository is teaching material rather than a library: it organises code smells into a five category taxonomy taken from an external classification, and it stores every example as a complete, runnable project so that you can detect a smell, apply a refactoring and watch the test suite stay green. The same snippet appears in several places, linked by symbolic links, which is what makes the before and after comparable. **CodelyTV/refactoring-code_smells-design_patterns** — ♻️ Example projects illustrating Code Smells in order to apply Refactoring techniques - Repository: https://github.com/CodelyTV/refactoring-code_smells-design_patterns - Website: https://codely.tv/pro/cursos - Stars: 595 · Forks: 138 - Language: PHP - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/codelytv-refactoring-code-smells-design-patterns ## A catalogue, an exercise set and a course link in one repository The repository is described as a showcase of the refactorings and code smells catalog, illustrated with practical examples in different programming languages. The title in the README is Refactoring from Code Smells to Clean Code, and the three links under the heading point to the paid refactoring course, to the star button, and to the issue tracker where you can propose an example. So there are three audiences. A developer browsing the catalogue wants to see what a smell looks like in a language they know. A developer working through the exercises wants a project they can refactor themselves. And a potential customer of the course wants to see the scope of what is covered before buying. The examples section of the README is marked as work in progress, and so is the refactorings section, while the code smells section is filled in. That tells you the shape of the project at this moment: the catalogue of problems is largely done, the catalogue of solutions and the example index are still growing. The repository is a PHP project by primary language, but the topics list Java, JavaScript, Kotlin, PHP and TypeScript, and the examples directory contains folders for csharp, java, js, kotlin, php, ts and typescript. So the examples are deliberately polyglot, and the primary language marker reflects the language the tooling around the repository is written in rather than the only language it teaches. The homepage points at the Codely courses site, and the repository is not archived, with the last push on 2026-06-03 and no GitHub releases. ## Five smell categories borrowed from an external taxonomy The code smells are grouped using a taxonomy that the README links to an external source, and it presents that classification with a short definition for each group. This is the part of the repository with the most teaching value, because the categories are the vocabulary the rest of the examples are written in. The five groups are: ```bash * Bloaters: Something that has grown so large that it cannot be effectively handled * Object-Orientation Abusers: Solutions that does not fully exploit the possibilities of object-oriented design * Change Preventers: hinder changing or further developing the software * Dispensables: Something unnecessary that should be removed from the source code * Couplers: Promotes coupling (knowledge particularities) between different classes ``` Read as a set, they describe different failure modes rather than different sizes of problem. A bloater is too big to handle. An object-orientation abuser works but does not use the features of the paradigm. A change preventer is code that makes the next change hard, which is a forward-looking property rather than a present one. A dispensable is simply something that should not be there. A coupler spreads knowledge of one class's particularities into another, which is the classic definition of a knowledge violation between two parts of a system. The change preventers category is the one that shows the difference between a smell catalogue and a lint rule list. Nothing in a linter can tell you that a class is a change preventer, because the judgement depends on how often and in how many directions that code is edited, which is a fact about a team's history rather than about the code's shape. ## The folder layout is a teaching device, not an organisation scheme The README explains how to explore the repository, and the explanation is the most unusual thing about it. There are three main folders, one for code smells, one for refactorings and one for examples. The purpose of the repository is to illustrate, with examples, how a code smell can be detected and a specific piece of code evolved by applying refactoring techniques. The mechanism is this: the code always lives in the examples folder, with a folder for each of its possible evolutions, and it is linked from the code smells and refactorings directories using symbolic links. So the same snippet can exist in several states, the version with the smell and the versions after each refactoring step, and the documentation pages for the smell and for the refactoring both point at those states through symlinks. When you open the code smell entry you see the before state, and when you open the refactoring entry you see the after state, and they are literally the same files on disk. The advantage is obvious once you use it. A reader comparing two versions of a class is looking at the same project directory, with the same test suite, at two points in a sequence, so the difference is the refactoring and nothing else. A reader who wants to try it themselves clones the project, opens the folder for the evolution they want to attempt, and runs the tests. The cost is a repository with a lot of symlinks, which is worth knowing before you clone it. Symbolic links are handled natively by git on Linux and macOS, and on Windows they depend on the checkout settings and the developer mode flag, and a download of the repository as a zip archive will contain the link targets rather than working links. If you are on Windows or you want an archive rather than a clone, expect the directory structure to look flat. ## Every example is a runnable project with a test suite The README is explicit about a design decision that matters more than it first appears: the examples are completely operational projects that you can open in your IDE and start refactoring by executing the provided test suite. The reasoning given is about learning. To get a better learning experience you need the whole picture of the specific code snippet you actually want to analyse, and that gives you the freedom to modify it right after cloning without having to worry about boilerplate aspects. So this is not a set of snippets in documentation. Each example is a small project, with its dependencies, its build configuration and its tests, that behaves like a miniature codebase. The test suite is the safety net for the refactoring exercise: if you extract a method and the tests still pass, the behaviour is preserved. That framing also tells you what the repository is not. There is no library to install, no plugin to configure and no service to call. The value is entirely in the examples, and the work you do is the work of refactoring them, which is the point of a kata. For a team that wants to run these as an exercise session, the operational projects are what makes it possible: clone, pick an evolution folder, make the tests fail by writing the improved code, and let the suite tell you when you are done. The README also asks contributors to open an issue explaining how they want to contribute before starting to code, so that the approach can be worked out together. ## The tree has more folders than the README advertises There is a small discrepancy between the documented structure and the actual one, and it is worth pointing out because someone browsing the repository will notice it immediately. The README describes three main folders, for code smells, refactorings and examples. The top-level listing of the repository shows five directories: code-smells, design-patterns, examples, exercises and refactorings. The two that are not in the README are design-patterns and exercises. Design patterns have their own directory, which makes sense for a refactoring catalogue, since a pattern is a solution to a recurring problem and the same catalogue logic applies. The exercises directory suggests a separate set of material, probably the practice pieces as opposed to the worked examples, but the README does not describe how the two relate, and it does not mention either directory in the exploration guide. Underneath, the examples directory holds one folder per language, with csharp, java, js, kotlin, php, ts and typescript. The presence of both ts and typescript is worth a note, since those two names usually mean the same thing; whether one holds older material or a different configuration is not explained in the README. The top-level listing is otherwise minimal, a README and the five directories, which is consistent with a repository whose content lives in the example projects themselves rather than at the root. ## Licensing and maintenance shape how you can use it Two facts about the project limit what you can do with it. The first is licensing. No licence is recorded for the repository, and the README does not include a licence section. That is a different situation from a project with a permissive licence, because the absence of a licence means there is no grant to copy the code at all. Reading these examples in order to learn from them is one thing, and lifting a class from a PHP example into a commercial product is another thing that the repository, as it stands, does not permit you to do. The second is the state of the work. The refactorings and examples sections of the README are both marked as work in progress, and the examples are described as work in progress too, so the catalogue is a snapshot of an ongoing effort rather than a finished reference. The last push was on 2026-06-03, the repository is not archived, and it publishes no GitHub releases, so there is no version to pin and no changelog of published states to read. Given all that, the realistic uses are learning and teaching. If you want a catalogue of code smells to browse, it is a well organised one with a taxonomy attached. If you want an exercise to run in a workshop, the operational projects with tests are exactly right. If you want to copy code into a product, the missing licence stops you, and that is a question for the maintainer rather than something to work around. ## Conclusion This repository fits a developer who learns refactoring by doing and wants a worked example with tests to run against, and it does not fit a team looking for a reusable tool or a catalogue to lint against, since the taxonomy is one author's grouping and nothing here is machine readable. Before you start, check the language folder you need under the examples directory and read the test suite first, because the tests are the contract that the refactorings preserve. Note that the refactorings and examples sections are marked as work in progress, the last push was on 2026-06-03, and no licence is recorded for the code. ## FAQ ### What does the CodelyTV refactoring repository contain? It is a showcase of a refactoring and code smells catalog illustrated with practical examples in different programming languages. The code smells are grouped into a taxonomy taken from an external source, and the code for each example lives in the examples folder with a folder per evolution, linked from the code smells and refactorings directories using symbolic links. ### Which categories of code smell does the repository use? Five groups: Bloaters, which have grown so large they cannot be effectively handled, Object-Orientation Abusers, which do not fully exploit object-oriented design, Change Preventers, which hinder changing or further developing the software, Dispensables, which are unnecessary and should be removed, and Couplers, which promote coupling of knowledge particularities between classes. ### Which programming languages do the examples cover? The examples directory holds folders for csharp, java, js, kotlin, php, ts and typescript, and the repository topics list Java, JavaScript, Kotlin, PHP and TypeScript, although the project itself is marked as PHP by primary language. ### Can I run the examples and refactor them myself? Yes. The README states that the examples are completely operational projects you can open in your IDE and start refactoring by executing the provided test suite, so you can modify the code right after cloning without worrying about boilerplate. ### How do I contribute an example to the repository? The README asks you to open an issue explaining how you want to contribute before starting to code, so the maintainers can help work out the best approach. There is also a link to propose an example in the issues tracker. ## Sources - [CodelyTV/refactoring-code_smells-design_patterns on GitHub](https://github.com/CodelyTV/refactoring-code_smells-design_patterns) - [Issues](https://github.com/CodelyTV/refactoring-code_smells-design_patterns/issues) - [Project website](https://codely.tv/pro/cursos) - [README](https://github.com/CodelyTV/refactoring-code_smells-design_patterns/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/codelytv-refactoring-code-smells-design-patterns