My name is Ashish Mahabal and
I'm going to be talking about
the best programming practices.
This is the first part of that.
The best programming practices,
there are many generic ones in that, but
also depend a lot on which
programming language that you use,
which package that we use and so on.
We'll be seeing some of
the general ones and
then we'll try to go into details
of only a few specific ones.
Some of the things that you'll
need to remember are first thing,
your code divides the universe into two.
And if the code is good, then it is
going to lead to a better universe, and
that is what you should try to do.
And that is one purpose of telling
you a little bit about some of
the best programming practices.
And this will be not about just
the programming language, but
also some related aspects of that.
And the best practices related
to programming begin not with
the program itself, but in that come in
very specific things like variable names.
Radius subroutines, the structure
of the program, and evolution and
well-being of the program itself.
So, what does one mean by that?
It's easy to, to coding just by instinct,
use variable names that are single
letter like a, b, c or just x, y, z and
that is a bad thing to do, because.
At this problem the moment seems fine, but
when down the line, later on,
you come back to that, or
someone else is reading the code, then
they may or may not make sense to them.
And you sometimes send to all
write such values easily.
So, you need to be a little bit
careful about what variables that you,
the names of variables that you use.
And then how to write those
will come to that specifically.
The other component,
the slightly bigger component is
the sub routine senior program.
Those are the most critical parts and
program, because they determine
the structure of a program, and
coming up with proper ones for
the names and the functionality is good.
So we will be seeing how the structure
of a function should be.
What the function should be doing.
How the different functions should
interact with each other, and
how they should be dependent, and
not be dependent on each other as well.
And that, in general,
defines the structure of a program.
That then leads you to
the evolution of the program,
because it rarely happens that you write
a program, and the program stays as it is.
Because down the line, you think of
new things, or bugs are reported, so
you are going to go and change that,
and the program is going to evolve.
So, when you start writing a program,
or a package, or a module.
You have to keep in mind that this
evolution is going to happen, and
you have to plan for that accordingly.
And the well-being is in terms of
the maintenance of the program.
You will be maintaining the program
initially or if you are part of a team,
the team will be maintaining the program.
So that too has to be kept in mind.
The program, the [INAUDIBLE] has
to be written in such a fashion,
that the maintenance is
also going to be easy.
So there are distinct function that
are distinct ways in which you can use
the best programming practices, and
depending on language
that's going be different.
But one of a generic book
that I can suggest to
you is The Pragmatic Programmer.
By Andrew Hunt and David Thomas,
you should definitely take a look at that.
For our specific programs, like Phyton.
There are some [INAUDIBLE] and
we'll be seeing more of that but
import this is the standard
thing that you can and
that tells you what kind of
functionality that specific best
programming practice that can bring
in [INAUDIBLE] seeing more of that.
Now before going forward with any other
specific comments one meta comment I
would like to make about best programming
practices is using source code control.
That is one thing that will be
the most benefiting to you and
your other team members.
Source code control, allows you for
different versions to be stored.
That's one of the things.
And there are many other
benefits of course.
So, typically, a new programmer starts
having, writing the first program,
and it may be called something
like MyProgram_1.pi, for instance.
[SOUND] And
then the program is written, it is run.
Something is done with it.
And then,
when some changes are to be made.
Invariably, the program
becomes MyProgram_2.pi.
And soon enough,
it becomes MyProgram_3.pi.
And then it can be 3A and 3B.
Where you had some subroutines,
take some subroutines out.
You combine some subroutines and so on.
And soon enough you forget,
which subroutine had which
changes that were made,
and what are the functionalities that
either you took out or took in and so on.
So, in order for
making all that transparent,
you can use Source Code Control.
And what Source Code Control
allows you to do is,
multiple people can work on the same
piece of code in a transparent version.
You can keep one making changes to
your program, and comment it so
that they all stay in a coherent fashion.
And there are many different systems that
get used for a, source code control.
The concurrent version CVS has
been used for a long time.
That problem, that has been solved for
a long time, but
there have been many changes and
improvements that have been made
over time, Apache Subversion is something
that get used a lot these days, and
Git is another similar
system that is used.
So we've seen a little detail of that,
but we can not go in to more detail, but
enough help is available on
these at radius location.
So, I encourage you to look at it and
use that lot.
So, let's quickly look at what cycle of
such a change through
Source Code Control can look like.
Here we see SVN cycle, and
there are four words you can see there
are checkin, checkout, comment, and merge.
So, the repository that you
see at the top of the picture,
that is where all the code sits.
And then,
you decide to interact with that code.
So typically, your first step is
where you make a local copy of it.
That is where you
are checking out the code.
Once you do that, then you're
free to make changes to the code.
And then update the code and add some
features, maybe take some bugs out.
And when you do that you will add
comments, what is it that you have done,
and then when it is time you will
want to update the committed
comment the updated quote and
that is where merging can come in.
Because if at the same time two different
people are working on the code, then it is
possible through something like SVN to
merge the code in a flawless manner.
And that is where you
check your code back in.
So this is the cycle that
you will typically be using.
Check out the code, make changes, update
slash commit, and which is your check in.
There are cycle for git is similar,
the diagram seems slightly different,
git is a more distributed system.
But, again you'll see that
our four columns here,
one is a workspace, another is index,
local repository, and remote repository.
So, what you do is that from remote
repository you can fetch some code.
That comes down to local depository.
And then your workspace,
you can make changes to that.
And through a command like add command,
you can tell that,
that has to be added to the index and
that should be looking at it.
And then when you do a commit, it
actually gets added to local repository.
So you can keep playing
around things can stay in
your local repository until you push.
When you push the core back, it goes
back into the central remote repository,
may not be a single location, so
it doesn't have to be central.
It's only notionally central, because git
repositories can be very distributed.
So, this cycle will allow you
to keep your code safe, and
let multiple people work on it.
If you get just one thing out of this
best programming practices video,
it should be that you should try to
use control as much as possible.
You want to regulate that.
And now many,
many online hubs are coming about,
where you don't really [COUGH]
have to have your own repository.
You can use something like GitHub or
Bitbucket where git is built in.
And that way what you do is that you can
fork someone else's code, or have your
own private or public repositories,
have other team members working on it.
Google Drive is something similar,
but for general documents, so
that's another thing you can be using.
Or if you want to write papers
collaboratively you can use a tool
like Authorea.
And if you are just interested in
latexing then there are sites like
sharelatex and writelatex.
Those are equally versatile in
being able to write papers.
So in general again source
code control will allow you
write code in different ways, but these
other collaborative tools which are really
mushrooming out there will
allow you to use do more work.
So coming specifically to coding.
You can start coding by instinct.
That is what everyone does, but that is
something that you should avoid doing.
So coming specifically to variable names,
there are many ways in which you can use
variables, and here I have mentioned five.
You can have the UpperCamelCase
where sometimes your
variable name has multiple words in it,
and you put the words next to each other,
such as all, except the first
letter of each word are lowercase.
That's why in UpperCamelCase you see U,
C and C to be uppercase.
That's one way of using variable names.
The second way is where you have only the
first word's first letter also lower case.
So lower, first letter upper case, and
then other lower case, and other words
also have their first letter upper case.
Now this is, in my opinion, the best one,
because the first case is, is,
some languages use upper case first
letters for their own keywords, and
that clashes with that whereas this lower
camel case doesn't clash with that.
The third possibility is all lower case,
but then it loses re, readability and
it's pretty bad in my opinion.
You could also have things that
are period separated, but again,
that clashes with some languages having
modules, which are used in that fashion so
that's again not a very good idea.
Or you can have things
underscore separated.
That is another good thing for
readability.
But then if you are using latex then you
may have to take special care of not
using it that way or
using a sensible lipec reader,
which knows when it is a variable
name that you are using.
So, in general one thing that I would,
I would advise is that you should
adopt a very consistent naming system.
Same thing goes four loops, there are many
ways in which you can write loops.
There are four loops and
y loops for instance.
And you should know the strengths
of the language that you are using.
That is another best programming practice,
because that will allow you to work with
the strongest points of the language.
In Python, for
instance, the four loop allows an else
clause so you can have a variable run so
many times, but once it is out of it,
the else part of it can also go in.
Or it can work with something like
dictionaries where you have got keys and
value pairs, and it will take one by
one all the keys and work on that.
And then, you should also know how
to avoid using explicit loops,
when the language has ways
of running faster the loop.
So here are some examples
that one can look at.
Think of this problem where you want
to add all multiples of three and
five below thousand.
A simple way to do that is indicated
at the top of this page here.
You can go from you can let your n go from
zero to 1,000 or below 1,000 and then if.
When you divide it by the three or
five, the remainder is zero.
You simply add that number,
and that's what your print.
So you get all,
you get sums of all numbers below
thousands that are multiples
of either three or five.
But you can do the same thing
using something like num pi.
And using modulus like these
which are easy to use,
makes the programming much more fun and
also faster.
Here, what we are doing is that we
are using a lube in an explicit fashion.
We're using the x and simply checking
whether it's divisible by three or five.
In the third case we are going
one step better, because here we
are not checking explicitly for
remainders but just stepping.
Through zero to thousand in steps of three
and steps of five, and then steps of
15 which takes out those, if,
if clauses making the program much faster.
So that is essentially what you need to
be able to do, using horses for courses.
And so, knowing all the strengths
of the programming language,
how to use different kinds of loops,
will allow you to do that.
So, besides variable names and
types of loops, there is also the issue
of formatting Python and Fortran.
They say you have to use specific
ways of in writing the code,
but the languages let you be more unruly.
And that can sometimes
lead to very bad code.
But if you are disciplined enough with
your indentation, with your brackets,
with your braces and
with your semicolons then your code
is going to be much better that way.
So the main thing to
do is be conscious and
consistent in the programming
style that you use.
And if you are that way then you'll
find that others find your code to
be much better.
I mentioned earlier about, import this.
And that started,
that came about as a poem, in fact,
that was written by Tim Peters in 2004.
It has 19 items in that.
And I am highlighting
only a few of them here.
So, one of them is explicit
is better than implicit.
And this is specifically, in terms of
typecasting, rather than do assignments.
As I said earlier four loops you can use
them in an implicit fashion but when your
namespace and when you have type casting
when you are saying that this integer
should be converted to flow to flow
should be converted to integer and so on.
It is better to be explicit about that.
Because otherwise what could happen is
that people can make mistakes there and
thereby reading the code may not be
obvious that is what is happening.
Then readability counts.
Even if you're very clever, try to avoid
being very clever in your programs,
because six months down the line
you may forget why you were being
clever that what it was, what the clever
thing was that you were doing then so on.
Similarly when you want to do a change.
Many times now is better than never.
If you want to add a feature you have
thought of it, it's better to do it soon,
rather than not do it at all,
because you have thought of it.
But at the same time the next
clause goes with that,
that never may be better
than doing it right now.
Because when you want to implement
some change, I mean you want to
do a modification to a program,
you need to put some thought in that.
If you don't do that,
then it's likely to cause changes
somewhere else which were unintended.
So rather than be in a rush,
be in a hurry, you better slow down a bit,
think about it, and then make the change
rather than just right away doing that.
The name-spaces are one
honking great idea.
Let's do more of those.
That is what allows you
to keep things coherent.
That is what allows you to not
muddy other subroutine spaces.
So you have some related terms.
They go together quite well.
And then if you use various
different kinds of terms,
very likely, other subroutines, other
programs are going to use the same ones.
And then you'll find that
one sub-routine spaces or
writing another sub-routine
space if you're not careful.
So, overall, this is how
a modification cycle should look for
any change that you want to do, any
programming change that you want to do.
The ones that in, that are in red,
we already seen that.
So, you check out code.
You make some changes to it,
you edit the readme.
And then after that, once you are happy
with that, you check-in the code.
So the part that is between
making the change and
check-in is compiling
the program of course,
when you make a change you
are going to see that it runs well.
And then you'll see more
things that are about testing.
We have not talked about tests yet.
We'll come to those in more detail,
but here I wanted to
point that out specifically as
a part of the modification cycle.
So, what you need to do is, suppose you've
got a program here that has certain
features, and on the right hand side
is where you'd like to go because.
This doesn't have certain he
wants to add certain features,
or this has some bags and you want to
remove those bags and reach here anyway.
So, you want to go from here to here.
Now clearly,
this final program will be able to loose
something that this program cannot do.
So, you should start by writing a test,
which this program is going to
pass with the program on my left
hand side is not going to pass.
And in the current state of the program,
clearly that test should fail.
You should ensure that it indeed fails,
because if it passes anyway, then clearly
what happens is that you don't really need
the modification that you're thinking of.
Once that happens then you
should check out the code.
Once you have checked out the code,
then you should make the changes
that you want to do.
Now come by and
now you are test whether pass.
Because you have made the change and
that is why the test is going to pass on.
And once that passes then
you can do a check in.
So that is where you're modification
cycle has been completed, and
if you follow that again for
all your programming changes.
Then your code is going to stay
healthy for a very long time.
This is a simple test that
one can see in python.
One can use data unit test module.
And here we are importing unit test, and
we are defining a very simple function.
The function fun takes one argument, adds
one to it and just returns that number.
So it's implementing
the input that it's assuming.
And then you see the last
statement of this program,
which is self.assertEqual,
which takes two arguments.
The first argument is
the call to the function.
And the second argument is what you
expect that call to return, and
the two have to be the same
if the test passes, and
that is what you essentially
need to make sure of.
So, when you call it by these two
arguments it's going return true,
if the test passes, you should do that
every time you want to make a change.
And we'll be seeing
more about tests later.
So, with that we come to the end
of the first part of this module.
Next time we'll be looking
at project requirements and
variousnesses in radiance of a program.