Clean Code C#

The Clean Code Seminar is scheduled for three days and is ideal for C# programmers who want to turn their own or others' code into significantly better code. Better code means: clearly structured, very readable, compact and efficient. Such code has a high quality and is characterized by the fact that it is easy to understand and extend. This so-called clean code is therefore very flexible, which enables even large development teams to react quickly to new requirements or changes. Even the most complex applications can be programmed faster, safer and above all comprehensible for others with clean code. This is very helpful for your colleagues and employees, for your employers or for your clients and customers who want to build on your code. The Clean Code course takes your code to the next level and demonstrably increases productivity and quality.

What do you learn on the first day?

As motivation for this exciting and important topic, we will first look at the four symptoms of bad code and bad architecture (rigidity, fragility, inseparability and opacity) and put ourselves in the role of a manager whose project is progressing very slowly and constantly produces errors. Deadlines are not met, teams are annoyed and customers are outraged and dissatisfied.

We find out what he should do now and for what reasons. Afterwards, we dedicate ourselves to the term "Clean Code": What is it about, how can you recognize good code and how can you quickly learn stylish Clean Code? In order to produce clean code, we need to apply certain rules and techniques at various points in our C# program. C# programs usually consist of several classes and interfaces. We now break down a C# class into its basic components: Identifiers (class names, variable names, package names, method names), comments, methods, and possibly exception handling.

This raises many interesting questions: What should my identifiers be called? How long should they be? How many lines should my method have? How many parameters should it ideally have? When should it return void and when should it return a value from a specific data type and why? When should I resort to exception handling, first or last? What is the level of abstraction in my methods and code? We will deal with all these questions in the Clean Code rules for identifiers, comments, methods and exception handling, using numerous interactive code examples (before/after or bad code/good code) as well as small programming exercises.

What do you learn on the second day?

After the first day you already know all the important rules for creating clean code, but only within a class. On the second day we dedicate ourselves to the questions: How should our classes interact with each other, how should we design classes in such a way that new requirements are ideally only possible through extensions and not through modifying and changing existing code. How and when do I decompose my class into multiple classes and why? How can I assign modules to Team A and Team B so that both teams develop independently? What is the meaning of the rule: "Program to an interface not implementation" that we read in every textbook about Clean Architecture and Code? How do we implement it correctly? We will answer all these questions with so-called SOLID and GRASP principles, using exciting code examples and programming tasks. SOLID is an abbreviation for 5 techniques (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle).

In our experience, SOLID is characterized by the fact that it is not easy to plan or implement. But if a programmer knows SOLID, he can immediately see if his program violates SOLID or not. If his program violates SOLID, then he can ask himself why: Are there good reasons for this? If the answer is no, then he can now very easily change his code so that it no longer violates the SOLID rules. However, we find the name "Principle" a bit exaggerated: SOLID are very good clean code and architecture rules, the application of which usually leads to a well-structured and clearly defined code. Nevertheless, SOLID should not and must not always be used blindly. Every now and then, there are also good reasons that speak against SOLID.

SOLID rules make the code flexible, but they also introduce more complexity. You almost always have to make compromises: If you need the flexibility, then you also have to accept the complexity. Therefore, every programmer should always ask himself the question: Why did I violate SOLID? Are there good reasons for it? In any case, every good programmer should master the SOLID rules, add them to his know-how and toolbox, and apply them with common sense. In order not to treat all this too abstractly, you will implement all SOLID rules by means of small programming tasks and see for yourself if and when this is worthwhile for you.

What do you learn on the third day?

We want to produce clean code, code that is not only easy to understand, but above all that works properly. Therefore, the topics of Unit Testing and Test Driven Development (TDD) are undoubtedly part of this. We will take a quick excursion into JUnit 5 and also into TDD, which consists of 3 phases (RED-GREEN-REFACTORING). Through simple examples and programming tasks you will get to know these 3 phases in action and quickly get a feel for them. If you are more interested in Unit Testing and TDD, you can also attend our separate course C# Unit Testing at the Munich Coding Academy.

Now you already know all the important Clean Code rules for one and multiple classes and even Unit Testing. What is missing now: In large projects you usually have to work with code that you did not write yourself. You should write new code based on existing code and therefore you have to understand it and modify and extend it if necessary. So how can you tell if the existing code quality is good enough or not? The answer is relatively simple: If the existing code violates the Clean Code and SOLID rules, and in addition has no or only poor tests, then the probability is quite high that it is code with poor quality. Exactly for this there is a catalog for the so-called Code Smells.

Code smells are code that smells of errors and complexity. This is even still very diplomatically expressed. Code Smells is code that simply stinks because it is so poorly written. Such bad code slows down development and reduces productivity and joy of programming. The first step to eliminate such bad code is to recognize it immediately; this is initially a matter of practice and experience. Nevertheless, there is a catalog for Code Smells (Names, Functions, Comments and Test Smells) with over 20 patterns. We'll look at the most important patterns for turning bad code into good code using lots of code examples and best practice techniques. This task: turning bad code into good code - is extremely important and very challenging, because it requires knowledge of refactoring patterns and can only be learned through intensive practice and many programming tasks. For this reason, we offer an additional course "Improve Your Java Code" for this purpose, which is the ideal companion for working with legacy code.

CERTIFICATE

Of course, as a participant in the Clean Code with C# course you will receive a certificate. Prerequisite for this is the complete participation in all course units and programming tasks and the successful programming of a small final project. This, however, will give you more pleasure than stress after this intensive C# Clean Code training.

The agenda is written in English due to the numerous technical terms. Descriptions as well as course material will be provided in German. You can book the course either in German or English.

All seminar contents are individually adapted to the wishes of our participants. They can vary depending on the level of knowledge and will be defined together with the seminar leader on day 1. In this Clean Code with C# seminar you have the choice of the following topics:

xUnit Test

• Life Cycle and AAA Rules
• xUnit Annotations
• xUnit Asserstions
• Parameterized Tests

Test Driven Development

• What is TDD?
• RED Phase
• GREEN Phase
• REFACTORING Phase

Code Smells: Names

• Bad names
• Unambiguous Names
• Encodings Names
• ...

Code Smells: Function

• Too Many Arguments
• Output Arguments
• Flag Arguments
• Dead Function

Code Smells: Comments

• Inappropriate Information
• Obsolete Comment
• Redundant Comment
• Commented-Out Code

Code Smells: Test

• Insufficient Tests
• Test Ambiguity
• Exhaustively Test
• Slow Tests