{Slide 1}

Welcome to EngX Clean Code program. I am Murali Rudraraju and in this video I would
like to give you the context of what Clean code program is and why Clean code
matters

{Slide 2}
Even bad code can function. But if code isn�t clean, it can bring a development
organization to its knees. Every year, countless hours and significant resources
are lost because of poorly written code. But it doesn�t have to be that way. ..
-Robert C. Martin

So have you ever been significantly impeded by bad code? If you are a programmer of
any experience then you�ve felt this impediment many times. We all have experiences
when we looked at some code to find our way, hoping for some hint, some clue, of
what is going on; but all we see is more and more senseless code.
Of course you have been impeded by bad code. So then�why did we write it?

Perhaps we were trying to complete a task and realized the mess we�ve just made and
then have chosen to leave it for another day. We�ve felt the relief of seeing our
messy program work and decided that a working mess is better than nothing. We then
said to ourselves that we�d go back and clean it up later. Of course, we didn�t
know that �Later equals never�.

This training program targets to help us write better code. Code that follows good
programming fundamentals and also some thing that is to understand when we look
back at it at later and also helps our colleagues understand and maintain easily.

{Slide 3}
If we look at most of the applications we work on, they will be maintained for a
significantly longer duration than the time or effort we spent in developing the
initial stable version. There will be newer features added overtime and often newer
features will need significant changes to the features already developed or the
underlying architecture defined initially. Its obvious that we know that the
quality of the code will impact maintenance. But what we should also understand is
that code maintenance does not start after the first version is deployed to
production. Even during the development phase, each time we add new code, we often
change existing code or our code is impacted by the dependencies our code needs.
This means that we are constantly refactoring code while we write in the first
place which means that developers are always in a continuous maintenance cycle.
Therefore we need to be cautious that before we end up with Bad Code, we need to
realize how to avoid it.

How do I know that I am dealing with Bad Code?

{Slide 4}
As a programmer you have probably been significantly slowed down by someone else�s
messy code.
If you are working on a project with large teams, the degree of the slowdown can be
even more significant. Over the span of a year or two, teams that were moving very
fast at the beginning of a project can find themselves moving at a snail�s pace.
Every code change breaks two or three other parts of the code. No change is trivial
anymore. Every addition or modification to the system requires that the confusing
code be �understood� before more be added which will cause more confusion.
Over time the mess becomes so big and so deep and so tall, we can not clean it up
until there is no way at all.

{Slide 5}
What is software Rot?
It the slow deterioration of software performance or responsiveness that will
eventually lead to software becoming faulty, unusable, or otherwise called "legacy"
and in need of upgrade.

This is not a physical phenomenon: the software does not actually decay, but rather
suffers from a lack of being responsive and updated with respect to the changing
environment in which it resides.

The reasons could be caused due to Unused code. Environment change which affects
the application behavior if the code is not updated frequently. Fixing software rot
is challenging but it can be prevented or we can atleast minimize the intensity by
following clean code principles so that the applications are easier to maintain.

{Slide 6}
Amongst the biggest impacted areas of bad code is application maintenance.
Usually most applications have 10 generations of maintenance programmers
Developers end up spending around 60% of time trying to understand code before it
can be changed.
There are very high chances that code that is complex will be difficult to test,
which means it also impacts testability of our code changes.
We will definitely end up having more bugs with complex code. Please note that
complex code does not mean it is a complex business requirement. Complex code is
usually an outcome of poor programming practices.

{Slide 7}
So What is clean code? Bad code does too much � Clean code is focused. Each class,
method or any other entity should remain undisturbed. Every object should have a
single responsibility, and that responsibility should be entirely encapsulated by
the class. All its services should be narrowly aligned with that responsibility.

It should not be redundant. We need comply with the DRY rule (Don�t Repeat
Yourself). When the DRY principle has successfully been applied, the modification
of any single element of a system doesn�t require a change in any other logically
unrelated elements.

Reading your code should be pleasant. When �browsing through the code you should
feel like reading your favourite book or at least a similar feeling. To achieve
this you should try to comply with the popular programming principles such as the
KISS principle (Keep It Simple, Stupid!) and YAGNI principle (You Ain�t Gonna Need
It)

Can be easily extended by any other developer. We don�t write code for ourselves ,
or worse � for a compiler. Code should be written to be easily maintained by other
developers. Don�t be selfish � think about the others. Don�t torture other
developers by producing code that is hard to maintain and difficult to extend.
Besides, in some months time you could be that �other developer� yourself.

It should have minimal dependencies.The more dependencies it has, the harder it is

Smaller the better. Code should be minimal. Both classes and methods should be
short, preferably just a few lines of code. It should be well divided (also within
one class). The better you divide your code the easier it becomes to read it.

It should have unit and acceptance tests. How can we know that our code complies
with the requirements if we don�t write tests? How can we maintain and extend it
without the fear that it will stop working? Code without tests is simply not clean.

It should be expressive. Expressiveness of the code means that it has meaningful

The next modules of this course will target the fundamentals of writing clean code
which will help us become better programmers.

{slide 8}
Thank you for watching!