 Good afternoon, so I'm going to talk about something that's dear to my heart writing beautiful code So before I start let me introduce myself So my name is Anand. I Teach Python professionally I conduct advanced programming courses at People Academy. I'm also a Co-founder of a startup called Roto data. We're building data science platform there So I use Python heavily at my work and also teach whatever I'll lend to students So let me start with the code from Christopher Alexander who coined the term the bad and language So it's really hard to say What is beautiful? Have you ever looked at the code and actually felt wow? This really looks awesome. Okay? I would felt raise your hands Yeah So And it's really hard to say when a code is what a code if you do what makes your code beautiful Okay, so it's kind of some people say it's Alexander Christopher Alexander says it's the quality without a name So you look at it. You kind of feel it but it's very hard to say so he talks in the context of Architecture but applies to many other art forms as well if you consider programming is also not So let me quote This from The way it's called a wizard book structure interpretation of computer programs This is the programs must be written for people to read and only instantly for machines to execute. It's a profound statement because Usually people we think programs are written to just get some job done. Okay, so we write for computer to execute something But if you look at it deeply programs must be for written for people the reason is If you look at the life cycle of any typical computer program Write once first time for the computer for the for the remand duration of the lifetime of the program Sometime I mean someone else look at the program up at some time. He has to understand the code or a lot of times What happens is we write a code and after a week or two We just can make sense of the program. I'm sure like all of us went through that face Okay, so it's very important to write programs to keep in mind of The people are going to read the code later point. So we should always try to improve the readability of the programs so Let me start with the very simple low-hanging fruit that everyone knows that I had to do it But not many people do this. Okay, choosing meaningful variable names. It's so important that Even people with a lot of experience fail to pay attention to this I teach Python professionally. I do Python advanced Python courses to Working professionals So I really find it frustrating when people with like three four years of program experience and I can't even pick right variable name It's not that they can't pick but just that we don't just pay the attention to those details I'm going to show you with couple of examples. How important it is to pick a variable right variable name So let me quote Phil Kaltran on that two hard things coupled signs are cash in validation and naming things Believe me naming things is not easy. It's hard What's the longest time you've spent? Banging you had to figure out what name to give to a class or a file name or a variable. I Remember having spending Literally two full days to figure out. What should I name this thing what I'm trying to implement. Okay, so Naming things takes time and we should give the time. Okay It's very very important to give that So the first tip is I want generic names that really don't make sense if you want to So what we do is you want to have temporary variable temp temp to manage your data It's kind of it's two generic names. You really can't understand what they mean had to use a little more specific names for example Yeah, so you choose a little more specific names to the context what that means The other thing is So the red is to indicate not so nice code and the green is one which is What's what I'm suggesting? So avoid using abbreviations People say UCF uppercase Formatter, but doesn't it's people can't understand what UCF is. It's okay if it's saying it's ETP or SMTP because that's a Well understood acronym. So that's fine But using something like BA for a bank account doesn't make sense. Okay, it's very hard to understand You can probably say formatter or an account or something. So That's a I think a good thumb rule. Don't use abbreviations unless that's very common. I think that Everyone knows This is another common mistakes that I keep finding in people as These data type has a name of the variable. They say it's a list It's a string. Okay, but list of what? String holding what right? So it's better to say Actually, what it says it says some of numbers Count words it takes a string, but actually a sentence. It's not a paragraph. It's not a file name. So It's better to say specifically what it actually Means not just saying the type of it. So that makes it a lot more readable the other a thumb rule about nouns and verbs is Use nouns for variables and classes Saying concepts and use webs for functions So saying actions. So these are the tasks that you want to do. So size price task scheduler, etc They go well for variables and classes and use actions get file name instead of just saying a function as file name So get file name so that it kind of indicates you're doing an action or mic account or a deposit So these are the kind of examples where Using webs makes sense for functions and Okay, they're not It's very simple rules not something that I've invented These are the age old wisdom that's been talked about from so many people if you Find out practice of programming or there's so many other books people have written But I'm just trying to take that wisdom and Put in the context of python so if you look at If you have a list of values, it's good to Use a plural for that So say a largest line Of lines or always start listed directly and you get files there, but Look at other Examples a file equal to always start listed directly. It's not a file. It's a list of files So better to use a plural to Say that it's actually a list of values and this these are examples actually Real world examples have Found from people when I'm doing teaching. Okay, so people say for lines in open filium dot read lines Reading read lines gives you a list of lines But each element is a single line not lines. So And saying into off lines doesn't make sense at all right, so It's better to use plural for a list and When you use loop indices These are y and j for loop Indexes only not for the values. Okay for example For i in range 10 is fine i is an index you're going over its values 0 to 10 But if you're going over a list of values using i it doesn't make sense because i is usually used for an index and If you're using i for numbers that feels like It's a single integer, but n could be a number or it could be a string or anything, right? So use something which is more Canvas what actually holds for any numbers probably more makes a lot more sense you might be thinking like Why am I talking about silly things like these are things what everyone knows, but it's really really hard to get this in practice Okay, let me show you an example This is a small filen function I've written. Okay Can you try and understand what this is doing? Can someone let's take a minute and then see what this does can someone explain me what this function does Wow awesome. Yeah, it's actually that's what it does. Okay, but let's look at this. Okay, so If you look at the same function I've written like that Okay, all I've done is I've changed the Names I'm not changed any structure of the program. So, uh, it's just a filen program And it's really hard to understand what is doing x and y and they're adding things to z. Okay So by changing the names it made so much of a difference. Okay Now by looking at immediately, you know that it's the data set It's an index and you're taking a row and then from the row you're taking Yes, I know I know but the thing is I'm talking about uh I agree so I picked this example because uh To show how much difference names makes I agree you can use this comprehension, but just uh trying to show how much names makes sense, okay, so If a filen code can make so much of a difference In picking the right variable names imagine what would happen if if you're working with the final line program or 10,000 line program, right so Uh, it's really really important to pick the right names so the other uh Thing is when you're using similar names For completely different data types. It's kind of very confusing. So when you're writing code, uh, you should also keep in mind what people think Unconsciously, okay, so when you see uh names which are sounding similar We unconsciously expect that they actually hold similar type of values. Say a1 and a2 You think they must be the same kind of values, but if you put a list in one other integer, that's very very confusing. It's very hard to uh, Make sense of that So probably say values are an instance of saying a1 and a2 And that's that's one of the issues that we had in the previous uh example as well We say x and y kind of feels like x and y must be the same types We may both are lists or both are integers or something, but they're not, okay Now let's uh Look at comments We all say people we all say writing comments is good, but uh, is it really when there's really no need to say the obvious, okay uh increment x by 2 That's okay. I mean python programmers We look at the python code and figure out the incrementing x by 2, but that's just that's the obvious thing There's no right need to write a comment But you can actually explain why you're doing it Compensate for border on both sides or you're adding one pixel on both sides So you're adding two so that makes more sense you're conveying why you're doing that So don't say the obvious say why you're doing that And a lot of times it makes a lot of sense when you're commenting, uh Add a comment to explain why you made the choice So the following is an optimization saves a lot of memcache cals So I'm saying that this is the reason why the following code is being done this way And also it's a good to document special cases for example, uh, You figured out there's an unicode error happening and you don't know why what's happening and this magically Fixes that issue. Okay, so Put a timestamp and say this is a special case. Uh, and this is how I'm fixing it So in future people will be careful when attaching that part of code and it's actually, uh Good if you can actually make comments redundant, okay Can write code such a way that you don't really need to write comments For example, if you look at the first case, uh, the fine length of the longest line So there's a list comprehension and finding the max of that. Okay Instead of that, if you say any code length of longest lines You don't really have to comment that it's kind of it's very clear in the program itself So you can write self-documented code. So, uh, the code is simple enough for people to understand by the Code itself, you don't have to write the documentation. So that's something Really awesome if you could do that Uh, yeah, the other thing is if you have longer functions What we typically do is you have stage one stage two add a block comment say that this is what So process documents and upload them to search engine and there's a part of code, but uh, it makes More sense to split that in two smaller functions and then say docs equal to process documents and then Submit to search engine. So you don't really need comments to explain that part of code now that we have looked at Uh, the simple things are more accessible things like variable names and comments. Let's look at Program organization. So how do you structure your program? So divide and conquer so split your program into smaller independent modules and functions That way it's a lot easier for people to make sense of that Let me code Miller's law what it says is Number of objects average human can hold in working memory seven plus or minus two It's a profound it has profound implications on uh how We should write our code reason is Seven plus or minus two is the number of things that you can hold in your head. That means That's probably means when you're writing a function You should not have more lines on that Or you have a class then a number of methods that in your public api should not be more than that So when someone looks at your class and then, uh, starts working on it starts using it If it has seven plus or two minus functions Then you're able to kind of keep all of it in his working memory and then able to work with it But if it has a lot of them, it's pretty difficult. So that's a kind of ballpark figure to keep in mind when you're writing, uh Classes or functions. So I think that's a good number to keep the size of a function as well and the Other common thing people always Don't pay attention as uh is duplication. So duplication is bad. Uh So for example, uh, it's a function. It takes an input data and tries to Uh, convert that to an integer and then sums them up and give the value back. Okay so Uh, since I'd say uh data is coming from users. We want to do some, uh Violation and converting integer before we actually do the summing up. So there's an uh try and accept But we're doing it twice if he's actually a deliberately added and So just people we write one thing and then copy paste and then modify things and Uh, you see I kind of uh deliberately left x here because that's uh, that's kind of errors that we usually get into. Okay, so Instead of duplicating we should it's a lot better if you can actually generalize that say, uh, uh, you get into Take input data and then uh x and y and uh, We're in x and y. So if you look at the add function here, it's very easy to understand now than what we had before Now, uh We should also avoid uh too many nested levels when you have a function. Uh, it may have May end up like writing code like this. Uh, uh, it's updating a blog post So there are many cases where you want to update a blog post You want to update a title or a tag So there's a big function that kind of uh going over the steps But if you see that too many levels of uh, Too many nested levels here. So that's kind of hard to understand So what can be done is uh, you can uh take each part of that and then make that separate function that really makes It a lot more readable. Okay. So if you look at this function, this function is just delegating it to uh, other sub functions So if you look at this function, it's easy to understand and if you want to the further details You can look at each of this, uh other functions The uh other uh useful thing is to make sure you handle errors separately. For example, this function is trying to uh get Uh user from given the email address So you first check if it's a valid user or not If it's a valid user, just make sure that the account is not blocked And then you query the database and give the user back But if you see the code of the function The main function of uh of this uh, this function is hidden in two levels deep Okay, so the query so that the level spreading is the is the core of the function, but that's Hidden deep inside uh So many conditions, okay So wouldn't it be wouldn't it be better that to be the most prominent part of the function? So what I can do is you can keep the errors handling uh separate For example like this. So we have you do the error validation first and then Uh in the top level you have uh the code of the functionality So you get a query and then uh query the database get the results and if you really trying to understand this function You could just skip the error validation and then directly jump to uh the main part of the function, which is Uh not so straightforward if you're uh doing it like this Now the other uh Very important thing is uh, we should try to suppress implementation detail as much as possible The reason is when someone is trying to understand program Uh the intent the what of what the program is doing and how the program is are doing are two different things So whenever someone comes to your program is is more interested to understand what the program is doing, right? So uh, we should improve it. We should suppress implementation details as much as possible so that you can understand, uh Uh The intent of the program pretty quickly quickly and then if required you can go and then see what uh each of those functions are doing For example, this program takes one common argument Which is a file name and then reads all the words in the file Computes the frequency of the words and prints the frequency. This is what the program is doing So it has four lines and this all the program is doing so the intent What the program is doing is very clear by looking at this program. Okay, but If I write a longer function and then put in uh, how the words are read and how Word frequency is computed right here in the same function, it becomes too difficult to understand why someone is doing it Now, you know, they're reading word frequency or computing word frequency I can go to word frequency function and figure out, uh, how it's actually being done the implementation Uh, the implementation and the intent can actually be separated the how and what it's good to separate those two things Uh, uh together So now that's I think, uh, uh The things that I want to mention about the writing beautiful core and this is a quick summary of what I've covered so far So choose meaning variable names. Uh, I can't stress enough how important it is It sometimes takes long a lot of time, but uh, it's uh, it's worth spending the time because uh The amount of time we spend later trying to figure out why the program is written like that Or trying to figure out how how this actually working Uh, uh, is a lot more if you don't spend enough time early to pick right variable names And use comments when required, uh, but don't put comments just because you have to Split the program into small independent modules and functions Avoid duplication at all costs Supposed implementation details and always optimize for readability Let me stop with a quote from tower programming Uh, a program should be light and agile. It's subroutines connected like a string of pearls So talking about the elegance of the program Uh, the spirit and hint of the uh program should be retained throughout Should have very the clarity of that you should have in the program There should neither be too little not too much neither needed loops nor nor useless variables There's a lack of structural rigidity and also need to have the right balance the program to make it beautiful Happy coding and I'm open for questions The slides of the talk are uh on my twitter feed if you can find out if you want to follow that I'm open for questions. So any Please uh for the mic Hi, um, so when you talked about the number of Objects that the human brain can track What's your opinion on the sort of recommended maximum minimum length of a code block? Sorry The the sort of recommended length of a code block So there's there's a school of thought that says if a code block is larger than n lines It becomes hard to read where n is said to be any number between 40. Yeah So I think thumb rule is it shouldn't be more than uh, half a page of sheets I think is what people say, but uh, I would say when my usual recommendation is not more than uh, uh 10 lines is what maximum I would say for a function So I would say like the 7 plus remains to rule it works for even number of lines in a function What are your thoughts on code formatters like yapf? So could please repeat I couldn't what are your thoughts on code formatting tools like yapf? uh, so Uh, I think it's uh, uh, I think let me repeat. So you're talking about the go for my tool, right? Yeah, I think it's a really good tool Uh, I think it's called the the bike share discussions I should be use one spare or two space or put a space before or after I think we just Uh, get used to whatever it is and I think go format go has really done very good thing about Uh, how you don't have options. You have just follow just one formatting thing But I don't think we have that luxury in python though. There's perpet It's up to the people to decide whether to follow or not I think it I would really love to have something like that for python So just a quick question on your thoughts on uh Something more specific about intelligible variable names Uh, I how I agree with most what you said. I think it's right I just wondered about this habit of deleting all the vowels in variable names like trying to Like picking a name and then abbreviating it by deleting all the vowels like I hate this. What do you think about it? this practice Oh, sorry. I didn't get good. Please repeat the question. Sorry. Yeah, so this kind of habit of deleting all the vowels and variable names once you've chosen a name that uh to try and make it shorter like some I guess there's a trade-off between variable length and intelligibility Yes, uh, so I think it's an important point. So I would say the variable the length of the variable should be proportion can be proportional to The scope of it is okay So for example, if it's a local variable if you have a function Which is five six lines doesn't make it. It's probably okay to have a single letter variable But whereas if you have a global variable, uh, which the scope is much larger It's better to be verbose and have the full name So if it is just a small function or inside of our loop, uh, I would say for w in words W kind of indicates it's a part of uh, it's an element of words. So that's a single word So that's probably okay to have a single letter, but I don't really like to Take out ovals or kind of make it Short just to uh I think readable is more important than the length of the variable. That's what I would say Thank you. I'm not in your opinion. What is a good time to clean up your code when programming? uh, I would say, uh It it's it's a it's a habit that you have to build over time. Okay. So, uh Uh Once we start keeping these things in mind when you're writing code or looking at someone's code You kind of feel that it's kind of violating that principle. Okay, so we should start getting that sense of Uh, identifying that bad smells so that when you're writing your code, you don't actually write that kind of things. Uh, so, uh, I mean probably when you're beginning Uh For a big nuts, it probably takes a while to get that habit. So we'll write it and then clean up But uh once you get through that go through that habit, you'll probably uh start getting that sense It kind of becomes your habit. I believe Any more questions? Okay, so thanks a lot and thanks