Welcome back to the Python course.
We are now in the fourth part of the software development and here in
the penultimate part on the topic of clean code.
Clean code is again a general topic, so it is not at all Python
-specific, but it is simply about writing clean code.
Try to write it in a way that it is good and easy to read, easy to
test.
I'm at the bullet points right now.
That you can simply reuse the code, especially if you think in larger
teams.
That in another developer you discover the work of someone else and
that you can integrate it and that you can easily change it.
It's basically about improving the developer's programming skills.
There is a central book and a central figure.
It is linked here.
You can go to the book from Robert C.
Martin.
Everything is described in great detail, what the principles behind it
are.
There is also a nice blog about it.
In the hacker circles, I'm not that deep into it, it's just called
Uncle Bob.
If you type in Uncle Bob in the search, you will come across a blog.
There are all kinds of clean code tips and tricks listed.
What makes the difference between a programmer who simply solves the
tasks and one who writes the code in such a way that it has a very
high quality and above all a good readability.
In principle, this can be summarized as follows.
Why should you deal with clean code?
It is a method to reduce and avoid the technical fault.
That would be the main point.
Simply keep the software soft and that you can read well what it's all
about.
You always have to keep in mind that you don't write software for the
computer, but for other people, for colleagues.
The compiler comes up with all kinds of things.
But whether the colleagues understand what you were actually going to
do, that's another story.
Therefore, if you write code that is very readable and understandable,
then you help to keep the technical fault as low as possible.
And simply to make accessibility easier for others.
You can actually compare that to when you write a book.
You've probably read books in the past.
They were just so crude and incomprehensible.
Maybe the content was good and it worked and everything was right, but
it was just not accessible at all.
And that's exactly what you can see here with clean code.
So you can solve a problem with programming languages, for example, in
very few lines.
But then it's written so complicated that only one or two experts
understand it.
Or you spend a few more lines and make it very descriptive, very
expressive.
And then a lot more people can understand it and also change and wait.
Here's a little link to a book when it comes to technical depth.
I made a link here again.
It's generally about the topic of software development.
In the course, we touch on some topics here, where you could actually
go deeper and hold your own two-hour lecture for the topics.
But of course we can't do that here.
So if you want to go deeper into the topic of technical depth and how
to deal with it, you have a literature link there.
Of course, a few more references.
There are a few more references to Martin's Clean Code book.
He wrote a whole series on how to become a better software developer.
Clean Architecture.
That's a topic we haven't talked about at all in Part 4 of Software
Development.
In addition to programming, it is also important how you design a
software, i.e.
a previous stage, what kind of architecture you are thinking of.
For example, where interfaces should be defined.
Whether you want to write it procedurally or object-oriented.
And if object-oriented, then which classes should there be and how do
they relate to each other.
Are there any heritages?
This is practically your own discipline in software development.
And there are your own jobs specifically for it, i.e.
software architects who have gone deep into it.
And that's a point we don't even touch here in the course, because
it's more about the code itself.
But if you are interested in something like this, i.e.
to work on a slightly higher level in software development, then I can
definitely recommend the book.
And then there is Clean Coder.
This is also a book that is very, very applicable.
You can find a lot of practical examples for daily use.
And in the Clean Code book there are also a lot of examples where you
read programming code and then discuss what is not so clean and what
can be improved.
And then he goes through his book and improves these examples.
There is such a Clean Code cheat sheet.
As is often the case with all topics, there are also very short
summaries for this.
You can take a look at that.
Or we can take a quick look at it together.
Here it is again on two pages.
So if you look at that, you will see a few principles that you should
use.
Here we have the picture with the technical depth, how it is then
created over the development period.
Why you should follow a Clean Code.
I'll just skip a little bit here.
Here in Environment, Project Build requires only one step.
So if you have such a project, then it would be nice if there was such
a central file or such a central instance where you just click on Go
and then the whole thing is built.
That was a bit in the chapter.
Continuous Integration, Continuous Delivery.
Here it is more about the Continuous Delivery, that you can expand it.
What else do we find?
Loose Coupling, that would be such a principle.
So you try to keep the classes really separated from each other.
If you write object-oriented, you can change them independently from
each other.
So there you will find the most important keywords in a very compact
form.
There are also other nice programming books.
So now purely for the craft stuff, to become a very good programmer.
There are some references to find.
There is also the book The Pragmatic Programmer.
From Journeyman to Master.
This is also quite new, it has been revised again.
And then there is a book specifically for Python code.
Clean Code in Python.
Refactor Your Legacy Codebase.
We'll get to the word refactor in a moment.
So there you have some sources if you want to dive deeper into
programming.
Which are definitely worth looking at.
Then let's take a quick look at a few concepts of Clean Code.
Let's start with a few quotes.
So writing clean code is what you must do in order to call yourself a
professional.
There is no reasonable excuse for doing anything less than your best.
This is actually an interesting quote.
Because you have to imagine that as a developer and as a programmer,
you are mainly responsible for the software quality.
There are often such quality departments and of course also management
level in the larger projects.
However, this is rather abstract for them.
So they are partly a layer above.
And really deep into the programming scripts and files.
They only have a view of themselves.
And that should be their drive to deliver good quality there.
This is a very important source.
Programming is the art of telling another human being what one wants
the computer to do.
So it's not about explaining to the computer what it should actually
do.
You can shuffle some scripts together relatively quickly.
And the compiler will then eat it up and implement it.
This is not the high art of programming.
You can do it relatively quickly.
But it is difficult to see programming as if you were writing a piece
of literature.
That's how I would describe it.
And someone else who then reads this should be able to see clearly and
without doubt what the programmer is actually up to.
So forget the computer in the background.
But rather think of another colleague who reads your code.
He should understand what's going on there.
That's why it's not always the smartest thing to program with as few
lines and as few characters as possible.
We'll take a look at that in an example.
But rather very descriptive, very descriptive programming.
The compiler and so on then translates it into machine language
anyway.
So you don't have to write with any hieroglyphics and very, very short
and very complicated.
This is only important in very rare exceptional cases when you then
program very, very hardware-like.
This is not always necessarily possible.
But we're not even at the level of Python here.
This is also a nice quote.
Computers are good at following instructions but not at reading your
mind.
So you always have to keep in mind what you're actually up to for a
plan and then implement it.
The computer is ultimately only very, very limitedly intelligent or
not at all intelligent and just implements it.
So you should always plan in advance what you actually want to
achieve.
In principle, everything that comes now can be derived from the two
quotes by Donald Kluve.
In principle, what I already said.
So what they really do is they don't write code for the computer, but
for another person.
So someone else who reads it, a colleague, for example.
And what is also important is that most people spend time in the daily
programming business.
So most of the time you actually spend reading with code.
It's not that much time with programming code writing that is spent
there during the day.
Especially when you're in a larger project, you have to orient
yourself again and again where you exactly are.
And that's where you spend most of your time with reading code and
then thinking about where to put your little changes that you have in
mind.
And of course it makes sense that the code is easy to read.
Then it makes the whole thing much easier.
So let's just take a look at that now.
This will not be a complete list of bullet points where it is about
clean code.
These are just a few things that I picked out.
An important point is that you should use very expressive variable
names.
Or not just variable names, but also functions, classes, methods.
So anything that you can name freely in any way.
Then it makes sense to use meaningful names that are just very, very
expressive.
So if you have a folder called test, then it's pretty clear to
everyone that tests are probably in there.
If you name the folder abstractly, just with a T, then it gets a bit
more difficult.
And above all, it is also very good if you simply search for larger
software projects.
So if you're looking for some kind of implementation and, for example,
something like Euclidean distance.
We have that as an example in a course.
And that means in some way distance or Euclid distance or in some
form.
Then, of course, you can find it extremely quickly with such a search.
And yes, of course, it makes programming code very easy to read.
If you have meaningful names in such a function or a script, you can
just read it aloud.
And then the code tells you what it's actually doing.
That's a very, very important point.
In terms of functions, there are also a few principles that should,
and this also applies to methods.
Methods are basically something like functions in a class.
Functions should be small, so always do only one thing best.
That means you write rather small functions with a few lines.
They should, of course, have these well-describable or well-explained
names.
They shouldn't do anything other than what they're supposed to do.
So if you have a plot function and it also deletes a few files
somewhere on the hard drive, then as a programmer you wouldn't
necessarily expect that, if you have the function that means plot
something, to clear up a few files right next to it.
That would be an example of a side effect.
That can be very unpleasant because you just don't expect it.
And then you should try to have as few arguments as possible.
So not that you have to hand over ten arguments first.
That actually indicates that the function is too complex and does too
many things at once.
And classes should also be rather small.
So whenever you program small, it's also easier to test.
Then you just have less lines of code and less, for example, logic
that's in there, so that you can write the tests very easily.
Those would be a few points on how to deal with functions, classes and
methods.
It's also very important that you don't repeat yourself.
We just said that you could see it as almost something like
literature, such a programming code.
And if you keep writing the same thing over and over again, it's a bit
like when someone else reads it, than when someone repeats themselves
over and over again and says the same thing over and over again.
On the one hand, that makes it a bit confusing.
And then you end up in a story that you like to call spaghetti gruel.
So it's the same thing over and over again.
Or there are dependencies with each other everywhere.
And that's just totally confusing.
You certainly know that when you listen to speeches or something like
that.
And if someone keeps repeating themselves and doesn't bring anything
new, then it's somehow clear that there's a lot of unnecessary
duplication.
And that it's just not clean and not well organized.
Towards comments.
There are also people who have the attitude that you should comment on
every line.
I've seen that before.
So you always write a comment before every line.
First a comment on what the line does.
Then the line comes, then another comment and so on.
And that's not the case in the principle of clean code.
So that's not favored at all.
But you have to remember that the comments don't repair bad code.
So if you have poorly readable code, then a comment on top of it is
not an excuse or an improvement.
And often comments are not on the same level as the code itself.
Because usually when you debug something or add a new functionality,
you work on the code.
But then you often forget to follow the comments.
And then the comments often point in the wrong direction.
They are maybe totally outdated and out of date.
And don't explain what the code is supposed to describe.
So few comments is actually the best solution here.
You should always try to express yourself in your code lines.
So this is another important point.
If you need comments, there are times when you need them.
But that should actually rarely occur in programming scripts.
That's always a good sign that you have programmed cleanly.
And that the code speaks to you or someone else what it does.
And then there are a few examples where you can use them.
There are of course such informative comments, if you just want to
have a few more explanations why something was solved.
This is also an important comment.
So you can also say that if you change a function or something, then
this and that can happen.
So other developers basically warned against consequences.
And of course what is often done is that you simply list a few
construction sites.
So this is implemented now.
But you should still improve this and that.
I didn't get to that now.
You find that pretty often.
Such to-do lists, for example.
So we just discussed that here.
Just comments that are bad, that lead in the wrong direction.
They are simply no longer up to date and are simply wrong.
So they describe something that the code no longer does below.
And then there are of course comments that simply say the same thing
as the next code line.
You can also save them.
Very often you can simply rename the variable names into something
descriptive.
And then you can delete the comment above.
The formatting.
It makes sense to stick to the conventions of each language.
That you stick to the conventions that have been implemented over
time.
And that's for Python the PEP8 Style Guide.
It will then be easy.
So if you stick to it and stick to the principles there, then you have
already won a lot.
We'll see that again in a moment.
Formatting.
Formatting basically means vertical and horizontal space between the
individual lines.
Just like the text here.
We have two points here.
And in between I made an empty line.
Books are also formatted and set.
And the same goes for programming code.
It's not like the words just hang here.
Or after the point that the empty mark is not there.
You could still read that, but it's very hard to read.
Or here after the comma also the empty mark.
It is important that you can read it well.
That's how you have to imagine it in programming languages.
And Python is a very nice example because it was actually designed to
be very easy to read.
So the formatting, if you take PEP8, then it will actually be very
easy to read by default.
And we'll take a look at an example.
So the PEP8 Style Guide is referenced here.
We can take a quick look.
Here we have the code layout, indentation, tabs or spaces.
We had that at the very beginning.
Blank lines and so on.
Whitespace, what that looks like.
Comments, inline comments, block comments.
Use descriptive names.
Function variable names.
So there you will find everything described how such a code layout
should look in Python.
And there are also such examples of how it looks right and how it
looks wrong.
So there you will find a very detailed resource.
Then the question of what you actually need clean code for.
We looked at the Continuous Integration and the code is tested there.
Then it doesn't really matter how you write down the programming code.
The main thing is that the computer understands it.
But of course it is so that you should read the code well.
And what came up earlier and should also be changeable.
In practical business, as I said, most of the time you spend reading
code to understand something.
And then of course it makes a lot of sense that you also have a clean
code.
Because then they just get along much, much better.
And maybe that again as a summary.
I heard that from a colleague.
If you automate a mess, you get automated mess.
That's what a colleague, an expert in the company told us again and
again.
Continuous Integration basically doesn't help if you don't program
cleanly.
Because then you can probably run a few tests.
But if you have the project in front of you, then you don't get along
at all.
And don't get along in this whole programming project.
There are just files in the wrong folders, for example, where you
wouldn't expect them.
Or the folders just don't have very descriptive names.
And then they just have a big text in front of them that is difficult
to read.
And then the whole story gets complicated.
So Continuous Integration is not the cure-all.
But there are also code analysis tools like FlakeAid and Pylint that
check such conventions.
And we used them before.
In addition to clean code, that was the level of the programmer.
So that you really look at the programmer's scripts and so on, the
files.
Are there other levels that are important to have a clean programming
project?
I briefly mentioned that.
The architecture should be properly designed.
We didn't look at that here.
The tests should also be written very cleanly.
We just gave a few examples of how to generate such tests with PyTest.
But we didn't deal with how to write the test in a way that makes
sense to test the code.
So that's also a separate chapter.
How to test software in a meaningful way.
That could also be a separate lecture.
That's a big field.
And there are also specializations that have experts for software
testing.
Then clean design.
That could be design for user interfaces and so on.
What is also important is the organizational structure.
If you work in an organization or a company where it is not so highly
regarded that you deal with bug fixes first.
But the most important thing is to deliver new features.
Then, as I said, the list of comments with TODO or NOT FINISHED and so
on in the scripts gets bigger and longer.
So you always have more and more small construction sites that are
built in.
And maybe you already have such a continuous integration pipeline
running.
But there you just see the quality metrics of the programming code and
the graphs.
They just go up.
So it gets worse and worse.
But if no one in the organization promotes that you even plan time to
improve the code.
So not to expand the functionality, but really just to keep the code
clean.
To keep the code base clean.
If that's just not planned, then you'll end up with a very complex
situation.
And at the end, or after a certain time, have a software product that
you can hardly wait to change.
And what you don't understand anymore.
And then you'll run into a dead end and have very high cost of change.
And that usually ends up in a task force.
When such a project slowly crashes, it is simply cut off again.
And then it gets pretty ugly.
And that's something you should definitely avoid.
But you also see the organization and the environment in which you
work.
It also has a very big influence on whether you can develop clean
software products at all.
This is a bit described here.
So what can happen here in this section.
So what can of course also be that you just have different business
units.
Where one person writes requirements and the other develops something.
And they don't communicate that well with each other or
asynchronously.
So you just don't work together.
Then that will also be a problem.
What makes sense to deliver.
That doesn't have anything to do with software anymore.
This is also the case with hardware products.
And yes, this is again about tests.
So that certain people just sell features that have not yet been
developed or deployed or tested.
This can also lead to inconsistencies.
This is exactly the case with hardware.
So if your organizational structure is in some way pretty messy and
unclean and works unclean.
Then this will also be reflected in the software that you develop.
And here on the right side this little comic by Geek&Poke.
This is actually partly the practice when it goes badly.
So here, in principle, what the programmer is doing is asked.
And he first writes requirement specification.
So at the very beginning which requirements the software should
actually meet.
That's at the very beginning.
Normally, we haven't dealt with that in this part of software
engineering.
Then he makes a technical design.
So he writes, for example, such class diagrams.
Or defines interfaces and then draws such overview diagrams.
That would be something in the direction of software architecture.
Now he starts writing test cases.
And then he quickly writes a system and user documentation.
And then the man with the green T-shirt looks at it and asks.
So tomorrow there will be an audit.
And he says yes, tomorrow.
So you basically developed software all the time and just built
functionality into it.
And all the other important steps that have to happen around the
clock.
That it works well.
You now draw them up very briefly before the audit.
And then it just adapts to reality.
Then of course you have the problem that if you write the requirements
afterwards.
Then it may well be that the software does something completely
different from what the customer actually wants.
So that's basically not the way you generate quality in general.
So the sheet should show you how to achieve really good quality.
You need a lot of different layers and levels.
So that's not just programming, but a lot of things around it.
And here in the course, as I said, we can't look at everything.
That would be a big lecture on how to make high-quality software.
We can only take a look here and there.
In the given scope.
We'll come back to Python code and take a look at a Python script.
What I wrote.
And I just made an effort to code the worst Python script ever.
And then we will improve the part piece by piece.
So we don't want to change anything about the functionality.
Just look at the programming code.
We want to make it cleaner.
And this work is called refactoring.
So it's basically the improvement of the implementation without
changing the functionality.
And that just improves the code quality.
And then avoids the construction of this technical fault.
So it reduces technical depth to a certain level.
And yes, this refactoring task.
It is important that this is also included in the projects.
Let's get back to the project management level.
To speak very briefly.
So if you still implement features.
And there one after the other with high time pressure.
Through such a development team.
Then it will be that the code is no longer readable after a while.
Because the programming itself happens so often.
That you have such a small draft that solves a task.
Then you think about it.
And then you write it better and better.
So there is almost no one who writes the perfect solution very cleanly
right at the beginning.
Programming is more of an iterative thing.
And let's take a look at a practical example.
And then you understand what this refactoring does.
And that it takes a certain amount of time.
And you definitely have to include them in the projects.
If this is not done.
They will build up a high technical depth after a while.
And then have very high cost of change.
And in the worst case, end up in some kind of task force.
And what I just described.
This is often a source of conflict in practice.
Because of course.
As many features as possible.
You always have to see where you steer the capacity of such a
development team.
And most of the time it is required that all features are traded in a
short time.
And if you act like that.
Then the development team does not have time to maintain the code
base.
And also the tests for example.
And also the continuous integration pipeline.
To maintain and maintain.
And that will just lead to.
As I said.
That the software is difficult to handle.
As a developer, you always understand worse and worse.
With the time what it actually does.
And that leads to errors in the end.
And also to frustration with the developers.
And yes.
Then in the end.
The task force always wins a little bit.
If you don't do it continuously.
And continuously.
Keep the code base clean.
Here is such a small script.
So up there in the cell.
These are the.
This is also stored as a file here in the repository.
This is simply called.
bat-smellingcode.py Here I tried.
The worst pipe code.
That I can get.
To write.
And just before you read that.
If you look at it as a block.
These are just a lot of characters.
So if you go a meter away from it.
You don't see anything.
Except a bunch of characters.
And yes.
It is very compressed.
On a few lines.
And yes.
It's just difficult to read there.
And to climb through.
It's just pretty confusing.
And what the script does.
It's actually something pretty simple.
So it plots a sine function.
Then something.
Which is a bit more choppy.
And then somehow another sine function.
The difference is here.
The axis scaling.
So that goes from minus 1 to 1.
And that goes from 2 to 4.
So that's kind of pushed up a bit.
Yes.
And then comes down again.
The browser doesn't show that now.
Again.
Such a choppy line.
So from the functionality.
It's not that complicated now.
But up there.
The block.
It's just pretty confusing.
The computer does that of course.
So the task would be implemented now.
In principle.
If that would have been the small functionality.
As a task.
I would have now.
From the scope.
Or from the functionality.
I would have implemented the thing.
In principle, you could stop now.
And say that's it.
And then check it like that.
On the master.
But of course.
If you want to use it later.
Then it gets difficult to read that.
So here is definitely missing.
In any case.
Whitespace and regression.
In all respects.
Yes.
It should hopefully also be difficult for you.
Just to read that.
That's a bit confusing.
And now let's start with the refactoring.
So we want to try now.
To maintain the same functionality.
So these plots should also come out.
We don't want to change any number values.
Or something like that.
But just.
To improve the type of implementation.
So that it is better for.
One himself and also for others.
Will be readable.
As I said, we always have people in our heads.
When we program something like that.
Not the computer.
The computer or the compiler.
He can deal with quite a lot of things.
And eats it already.
And does it already.
Now let's take a look.
Only the pure formatting.
So we now make horizontal and vertical.
Whitespace to it.
And then the whole thing looks like this.
So it's actually just.
Enter sign inserted and.
Empty sign.
And it already has a completely different structure.
You can see it here.
So once at the imports.
They are no longer on one line.
But they have two lines.
You don't have to read it at all.
But you know there are two imports.
And then there are such individual blocks.
So here is somehow a block.
He does something with data.
Then there is such a block here.
Code block.
He makes a picture.
And plots something.
Here there is again a picture.
And plots something.
Something with data.
Again picture.
So already alone with this horizontal and vertical.
Whitespace has won a lot there.
If you look at it.
You see now.
The program itself.
That has 1, 2, 3, 4, 5.
Somehow so 6 actions.
You could say.
And that's actually so similar.
If you write something.
So write a report.
Or so.
That it is simply divided into logical sections.
And logical sequences.
What comes one after the other.
Then you put such chapter headlines in.
If you write text.
Or such impressions.
Or just such a paragraph.
They would not now.
Book for example.
Or write a big report.
And there just always in the flow text.
Convey everything.
The content is of course the same.
But it is without structure.
And very inaccessible.
So only through this horizontal and vertical.
Whitespace you can already.
Win a lot.
And.
We have now.
More and more lines.
So the script is longer.
So through the empty lines.
And also through the ender.
We now have more lines to read.
But it makes it much easier.
Now we still have.
Such redundant code in it.
So.
If you just looked at it.
I said yes.
Data.
Then comes a plot.
Then again something with data.
Then comes a plot.
And the plots are of course very similar.
And now.
Let's take a look at this principle.
Do not repeat yourself.
So if you read it aloud.
I plot and I plot.
Then it always sounds a bit.
Copy and paste.
And that would be a version here.
Where they have a little less copy and paste.
There you can see at the beginning.
You have defined such a plot function here.
I also called it myplot.
So it is relatively clear.
If you call it later down here.
That something is probably happening with the picture.
And there you see now.
That is simply summarized.
A solution.
And if you look at that now.
You have here as a script.
You have a block.
Something happens with data.
And then you have a block.
Something happens with pictures and plots.
That makes it a bit clearer.
And this copy and paste from before.
That is then lost with it.
That has the advantage.
That if you want to change the plot.
Any colors or so.
Then you can do that centrally here.
So you can change the color from red to something else.
And then of course it works.
on both pictures.
So everything that is not redundant.
That is also easier to wait.
And easier to test.
So you just try.
To use things over and over again.
That should be the same.
That would be here in this case.
We go back briefly.
Not so.
That means if you make a K out of the R.
That would be for black.
And you do not just make two.
Or four pictures in a row.
But quite a lot.
Then you would always have that.
As copy and paste below.
And then it can be difficult.
To find this one mistake.
And then to find in which plot.
The wrong color has just been used.
That is with such an.
Encapsulation then of course.
Much easier.
So you have it in such a layer.
Packed in such a function.
And then you can develop that here.
And what you can do now.
With this function.
Is that you split the work.
That means you can give a developer.
For example, the task.
Just to take care of this plot function.
You can do that in another file.
For example.
And another.
He only deals with the data.
This is of course a very simple example.
But if you think of more complicated examples.
And then you can split the work.
And also individually.
The whole implementation.
So you can only test the data generation.
And only test the plot.
And then later assemble it.
And.
You can imagine that.
That this also happens on different branches.
And then in such pull requests.
Is built together.
That would be another advantage.
Of this type of implementation.
So we now have three sections.
There is such a plot part.
Where a function is generated.
Then there is some part of the data generated.
And then again.
Where this plot function is simply called.
And now we can look a bit.
That we still use meaningful names.
Which are simply more expressive.
There you can.
Now rewrite it a bit here.
So you could call it time.
For example.
Here the x-axis.
And I have it now.
Named well1 and well2.
You could also call it sine wave.
Um.
Biased sine wave.
Or something.
For example.
That would work.
And here at the plot function.
The arguments are now named differently.
They are now called time, values and noise.
And then the call on the right side is a bit clearer.
So with noise.
There should be some kind of noise.
Then this numpy random.
Makes a little more sense.
So that could be.
Possibilities.
That you simply use a bit more descriptive names.
As I said.
You can also come to other solutions.
Of course there is not.
Yes.
A single solution for it.
But it definitely makes it.
A little better readable.
And also easier.
Then to use.
So if you call the plot function.
Then it is somehow clear.
What kind of arguments are.
That was before.
In principle.
Simply given with x and y.
And we had here again.
The noise generation.
Built into the plot function.
That's actually something.
What you don't necessarily expect from the plot function.
That.
Data are generated.
Depending on something.
So that would be.
A time effect.
That appears inside.
That would make sense.
That you put it out.
And then you can.
Also the type of noise.
Set individually.
You can do that now.
In some way.
So you could.
Create new 1 and new 2.
And then different noise distributions.
Generate for example.
That makes the whole thing.
A bit more flexible.
Whereby the plot function.
Of course already has some arguments.
So somewhere with these three arguments.
You should then also.
Stop slowly.
And then rather.
The noise actually.
Pack to the data.
So you can already see.
You can think a lot about it.
How to do the structure of this little script.
Optimally designed.
That really depends on.
What you're going to do with it later.
And it's just quite often.
That the projects.
Develop in a certain way.
That means you have to.
Pack and adapt old code again and again.
And that's what I said.
A few minutes ago.
That you actually spend a lot of time.
With reading.
So if you think about it now.
We want to have different types of noise.
Then it might not be so clever.
To use this as an argument.
In the plot function.
But we'd rather do that.
Right at the data generation.
And just change the data a little differently.
And then you have to.
The arguments.
From the plot function.
And then they quickly change.
Again in files.
Which actually have nothing to do with.
Your current task.
And then we're back in.
Change old code.
And maintain and adapt.
We can do that now.
Let's look at this again.
With the new one.
That didn't quite fit.
And that's what the previous slide said.
That you think about it now.
We'd rather.
We just hand over a function.
Then this is done here.
That you just.
This.
Function of noise generation.
Then a little bit.
It's a little bit.
Then you can test the individual ones.
That would be a solution.
And you could.
With an argument.
Provide.
And then call differently.
Or as I said the noise.
Just build in here.
At the data.
At the data generation.
And then the plot function again.
Divide into two individual images.
So you see.
Two images are generated here.
You could also consider.
If you make a plot function.
For the first block.
And a plot function.
For the second block.
So you see.
Alone on such a small task.
You can think about it a lot.
How to make the structure.
And how to implement it.
And that's just.
The normal workflow.
When programming.
That you have such an initial solution.
And then think about.
How to implement it.
That it can be read well in the long term.
Can be maintained well.
Can be tested well.
Can be understood by other people.
That you can deal well.
With the code in the long term.
That was such an example.
I would not say.
This is the best solution.
As I said.
It always depends on the context.
How to proceed with it.
Or what the rest of the project looks like.
Then there is another option.
That you ultimately.
The data generation.
As a function.
So now we have quite a lot.
Lines of code.
That would be another option.
So here it is shown.
With this sine wave.
There we now have a function.
That only makes a sine wave.
Then there is this bias sine wave.
There you can now.
To the plot function.
Transfer various basic functions.
And in the plot function.
There is still such a point.
I do not quite like it yet.
There it is still in the second part.
From the picture.
And now they are quite flexible.
Now they can also.
Define other functions.
And down here.
Exchange and transfer.
That would be another option.
You see the script.
That will be a bit longer.
But it has more structure.
That would be the summary.
Now you can of course.
Use tools.
That was briefly mentioned.
To implement.
On the conventions.
And also on coding tips.
And that's just this.
Flake 8 library.
And the pylin library.
That was briefly.
At the continuous integration chapter.
But also.
Programming environments.
Like PyCharm.
They automatically look.
If you type code.
And give tips.
In the editor.
You can open the file.
In PyCharm.
For example.
There should be on the right.
In the editor.
What is worth improving.
PyCharm should give you.
A few tips.
Automatically.
But you can.
With code checkers.
Check.
You can try that.
You had.
Flake 8 and pylint.
Already integrated into the environment.
Then you can.
Download the file.
And then.
With pylint.
Batsmellingcode.py and Flake 8.
Batsmellingcode.py.
See what these two checkers say.
I'll show you.
What this has spat out.
You can try that.
They should.
Jump in.
And give some tips.
Here.
The result of pylint.
I got.
The code rating is.
Minus.
7 .7.
Of 10 points.
I have never seen.
There are all.
Conventions.
And good practices.
Programming.
Missed.
Everything.
Fails.
The best quality.
Is 10.
Most of the time.
Positive over 0.
But the script.
Beyond good and bad.
What I wrote.
Exactly.
You can.
Put the solution.
In a file.
And test it.
With pylint.
And think about it.
How to program it.
Start with the.
Batsmellingcode example.
And do a refactoring.
Task.
There is.
Support.
You can.
Mark code lines.
And refactoring.
You can.
Create functions.
Pycharm offers.
Help.
There are.
Videos and tutorials.
Code refactoring.
Something.
Occurs.
If you.
Implement something.
You will.
Have to.
Adapt.
That is.
A normal part.
Programming.
You adapt.
And improve.
That is.
Software.
Not hardware.
That was.
The chapter.
On.
Code.
I hope.
It was fun.
To follow.
How to.
Write code.
Look at.
The principles.
In the book.
I recommend.
For later work.
Then.
You can.
Learn.
From the best source.
How to.
Program.
Thank you.