 Thank you. Hello, good morning, everyone. Please call me Abbas. Okay. So, my topic today is tidy up your code, writing legible code. Now, what do you mean by legible? Anyone? I'm trying to make this session a bit interactive. So, please contribute. What is legible code? Readable. A code that is readable by not just you, but by other developers and other developers, people as well. So, let's see how we can achieve this. Hi, my name is Abbas Ali and I run our development company called as Rainium Systems. We are located in Nagpur and we are a team of around 40-45 developers here. I have been working in PHP since 2004. It's almost 18 years now. Our primary focus is creating these products using Laravel framework as well as we take on other technologies like WordPress, Drupal, Joomla, Magento and all those things. So, let's start. What is readable code? Readable code is a code that clearly communicates its intent to the reader. Now, why is this important? Why should your code communicate with you? Right? We'll see. First, let's start to understand what is a good code. A good code is a code that works. That is the most important quality. Your code should work as expected without any bugs. Otherwise, we cannot call it a good code. Then your code should be readable and understandable by everyone including new developers, junior developers. It shouldn't happen that the code that you write is only readable by yourself and no one else. Kids should be able to read and understand what's written. That is what is a good code. Why is it important to make your code readable? To collaborate with the team. One, that we want a code not just to be readable by us but also by some other development team who may pick up our product, who may pick up our code base and work on it, let's say, six months on the line. Not just that, but also, most of times what happens, we write some code, the project is delivered and then we forget it. Then the client comes back to us. He asks for some changes. He has to add new features. And if we read our own code, let's say after one year, we're not able to understand a bit of it. That shouldn't happen. So, you should write. In the first place, you should write the code such that it is readable by not just by other people but by also by yourself as well after a period of time. So, let's see how we can make our code more readable, more legible. First, we'll try to improve the appearance of the code. Without changing the code, just by making some appearing cosmetic changes, we can make our code look better and readable. Appearance, as you know, is the single most important thing. As a human being, we also want to appear best. Why? So that other people like us. Similarly, our code should also look best, should appear good, so that the other developers who are looking at it, they like it. How to make the code appear better? We'll start with formatting. First is following certain coding standards. In PHP world, we have PSR coding standards. How many of you know PSR coding standards? And I hope you are following the same as well, right? So, one should follow the standard coding conventions that makes sure that your code is consistent. The most important thing is your code should be consistent throughout. It shouldn't happen that you are following some other conventions in one file, one class, and in another file, you are following some other convention that will make your code very hard to read. Also, following coding conventions makes your, formats your code better. And lastly, it makes your code PHP CS Fixer. What does it do? This is a tool, a script that will read your code and it will make sure that it follows the standard convention. It will rewrite the code for you automatically. So, I highly recommend that when you go try PHP CS Fixer, it has plugins for all the languages, not all the languages, sorry, all the frameworks, all the CMSs including WordPress. So, if you're writing code, use PHP CS Fixer to fix your code. It also has VS code plugins, PHP Storm plugins as well, available for PHP CS Fixer. So, after formatting comes spacing. Adding some spaces in your code, it will make your code more readable. Let's see. This is a function, a very simple function. As you can see, everything looks a bit messed up. It is not readable. But if we add some spaces, we are not going to change any code. We are just going to add some spaces, much more readable now. Or no. So, always add spacing. It gives your code breathing room. Spacing doesn't cost a thing. It's not like that adding spaces will make your code run slower. That never happens. So, put ample spaces in your code, especially before and after each block. This is a block of code. This is a block of code. So, whenever you are starting a new block of code, make sure you add spaces before and after that block. That will give your code a much needed breathing room. Next, to make your code appear better, again, a very simple function. We are fetching some data from database and then returning that user. This is a very small function. There was a lack of space. That's why I wrote a very small function. But assume that this is a big function with 10, 15 lines. If you are just glancing this code, it is very hard to understand whether this function is returning something or not. Because this return statement is getting lost in all this code. It is not readable. So, again, just adding one empty line before your return statement, this return now stands out. Now, you can quickly see what your function is returning. So, always add one empty line before your return statements. One thing I forgot to tell you, all these, whatever I'm saying, whatever you have been doing, it's not like that you have been doing it wrong. This is an opinionated talk wherein what I like, I'm telling you, it's entirely up to you. Of course, you might be having some better ideas. So, yeah, just wanted to put that out. Then, return early. What this means? Here we have a function. We are getting ideas as a parameter. Then, we are fetching the user from database. If we are finding that user, then we are performing the logic. If we are not able to find the user, then this is a negative test case. This is a negative case. Right? Return false. Again, this is a short function, but this can be a very big if block. Right? This if block can have 10, 15 lines. Your main business logic. Now, why this is a bit hard to read? Because if this, if it's very big, then you could see what's happening in else, you'll have to scroll down a lot. Right? Now, we can change this a bit and make it much more readable. What we are doing now here? We are returning early. Return from your functions early. That means whatever negative cases are there, handle them first in your function calls. In programming, you should always, for example, when we are processing a form. Right? The request comes in. The first thing that we do is validation. Right? Similarly, any other negative test cases should be handled at the top in your function. And rest of the code can be the main business logic. So, this avoids the else clause because if this fails, we are returning early. This makes this entire code much more readable. You know what will fail this function. This will fail this function. And you can know right at the top. Next, we'll see how we can arrange the variables so that they are more readable. Here's an example. People at the back can see the code. Right? It is readable. We are creating two dates. Start and end date. Right? But if I ask you, let me know what the date is. Who can say what the date is? Start date and end date. There was more time lagging. Right? Because, sorry, start day is here. Year is here. And month is here. Then day, end day, end year, end month. To form the date, you have to look up and down, up and down. So, instead of this, just rearrange the variables. And now, and also arrange them in the proper order so that you can instantly read what the date is. Now, we can say it is second Apple 2022 start date and end date is 3rd June 2023. Very easily readable. Just by rearranging the variables. So, we are done with appearance. Now, let's see the next topic. Nomenclature. What is nomenclature? Naming things. Right? Nomenclature is naming things. This is one of the very famous computer programmer from the old days. He has said there are only two hard things in computer science. Cache invalidation and naming things. Naming things is really tough. It's not easy. It seems easy, but it is not easy at all. How to name your classes, how to name your variables, how to name your files. Why naming matters? Naming is communication. How do you communicate with people by calling their names? Right? Similarly, to communicate with your code, you need to have proper names to your functions, methods, classes, and files. Code with sophisticated names is hard to read and understand. If you give, let's say, if you, everywhere you use dollar A, dollar B, dollar C, will you be able to read your code? Understand what's happening? No. So, proper naming makes your code readable. And of course, if you give your methods or classes names properly, then people can understand what's happening just by reading the names. They don't even need to look at the logic, the entire code. Right? Create user class. Just by name, people will know, okay, this class is responsible for creating a new user. They don't have to read the entire code. But if your class name is just, let's say, user, then they won't know what's happening, even though it is creating the user. Who's this guy? He's the one who is trying to read someone else's code, and they have given very bad namings to their variables functions. So, he's frustrated completely. Now, how to name things? We need to use proper language. First and foremost, always use English language while coding. Your code should always be in English. Why? I'm not here to promote one language, but English is the standard in the entire world when it comes to programming. I know nowadays many programming languages or editors and everything supports emojis and UTF it characters. You can use those to name your variables in classes, but don't do it. It is okay for fun, but not good in practicality. Always use plain, simple English language, not just to name your functions, methods, variables, but also to name your, say, what also to write your comments. Comments should also be in English. Choose your words. Words means how you name. Choose that properly. When you're, for example, you're writing a class or a function. Think about it. What do you want to do in that method? What do you want to do in that class? Come up with a name for that. Don't haste into naming things. Take Google's help to search for synonyms. I'll give you an example. For example, you are dealing with head of a school. You want to write a class which represents head of the school. So you can name the classes head of school. Easy. Correct? But if you think properly, give it a minute, then you can come up with a better name. What is the name of the head of a school? Principal. A single word. This was an easy example. But in many cases, for example, you're building a feature wherein you're logging in as another user. You're building a feature to log in as your super admin and you're logging in as another user. So what will you name this function or class name? Guest. No, no. You're authenticating as someone else with the user. Switch user. Yeah, that can be a name. But a better name, a synonym for this phrase is impersonate. You're impersonating as someone else. So your class or function name should be impersonate. Excuse me. Similarly, if you're dealing with photos, videos, audios, what will you name that class or file, whatever? Photos and videos. Photos and disco videos. Media. So think in this manner. Give it a moment, search on Google, your phrase, put that in Google, search for it, it will show you the single word synonyms. Use those. Then remove redundant words. Sometimes we tend to add some words to the functions or methods or file names which are not needed at all. Example, we can have a function called as create underscore new underscore user. Create new user. Since in our course, harmful like that, create new user. But the new word is not needed at all. Creating means new, something new. So it should be just create user. No need for the word new there. So like this, you can get rid off a lot of redundant words as well. Then avoid abbreviations in your code. We have a very simple function. Everyone's favorite, calculate salary. Dollar B, dollar HRA, dollar TA, dollar ink, dollar TDS. This is good. But what is dollar B? What is TA? What is ink? If someone knew who doesn't know this, how salaries are calculated, what are the different components of salaries, they won't be able to understand this. So you should avoid abbreviations when they're not needed. So it should actually be not dollar B but dollar basic, basic salary. Travel or TA, travel allowance. Instead of dollar INC, write full words, incentive. But you can see I haven't changed. How's it allowance? It is still HRA. Why? Because this is an accepted acronym for how's it allowance. Everyone knows it is known as HRA. So you should make that judgment, which acronyms will make sense to other and which acronyms may not. No one calls basic salary as just B. They call it as basic salary only. That's why you should write basic salary. Similarly, TDS, everyone knows TDS is an accepted acronym. Prefix, variables and methods. What this means? Here's a very simple function. We are fetching a todo from database. And then this is the method. We are calling a method called as completed on todo object. But just by reading this, we don't know what this completed method is doing. Whether it is marking the todo as completed, or whether it is determining whether this todo has been completed or not. It can be both. This may be changing data in database, or it may be returning something, reading something. So if we just add simple prefixes, it will make it much more readable. todo is completed. Now just by reading this, you know it is determining from the database, fetching from database, whether this todo is readable or not. It will return true or false. You'll also know what is the written type is completed. So written type must be a Boolean, true or false. Similarly, you can add prefixes to function. Here we have two methods, functions, findUser and findRemoteUser. Now the difference between these two functions are this is finding the user running a SQL query on local database and fetching the user. This is getting the details of this user from some remote service. It can be an API or some external service, XYZ. Now I have named it to find remote. That is why you can understand that it is doing from remote. But in real world, we don't generally use remote word. We use something else, findUser, something. Now you can follow a certain convention so that you are able to understand whether this reading is happening from local database or from some remote service. For that, whenever reading from local database, you can use the prefix get. Get underscore user. This will always mean that you are reading from local database, getting from local database. And if you're reading from some remote service, then use the word fetch. Browser may be edgics calls fetching. So just following that same convention. Fetch means fetching from some external service, external API. What is wrong here? First underscore name. This is a snake case. This is camel case. This is Pascal case. The programmer has used all sort of different naming conventions in the same file or same code. Never do that. Whatever convention you are using, whether it is a snake case or camel case, stick to it. I have seen this many times, people are using one underscore and another camel case. Don't do that. Be consistent. Whatever convention you want to use, but be consistent with naming variables and methods. This is a trick that I commonly use. Use time stamps instead of booleans. Many times we want to store in database whether a particular thing is completed or published, for example, blog post is published or not, whether something is deleted or not, active or not. So we put it in a boolean field in database. And we name it as such, completed. This is fine. We can know whether this is completed or not. But we will not be able to know when was it completed. For that, we'll have to add another field, date time, to store this information. If you're completing something, when is it completed? What time it was completed? So instead of adding two different fields, what you can do is just use a single field, timestamp field called as completed at. And its default value in database should be null. So it's completed at timestamp field is null in database. It means that thing is not completed. If it has a value or timestamp, then it means it is completed. It was completed and it was completed at that time. So two fields from one third. Now the last section, I guess, is code format and refactor. We'll see how we can refactor our code to make it more readable, only if there was no else. As I said earlier, always try to avoid else's. Else write, leave it to yourself. See this code. If can there if else, this is very small code, small function, but I have seen five, six, if, if, if, if, if. And then else, else, else, else. Makes your code very hard to read. What's happening here? If the user is active, then we are checking if he is subscribed or not. If he's subscribed, we are sending him a subscription email. If he is not subscribed, then we are sending him a marketing email. Okay? And if user is not active, then we are sending him an activation email. We'll refactor this code. It will do exactly the same thing, but the code will look better. No else's. If user is not active, this was the negative test case. Again, what we saw in the beginning. Always handle the negative things first in your methods. If user is not active, we are returning early again the same rule. Return early. Sending the activation email and returning early. Then if user has subscribed, then we are sending the subscription email and returning from here. So no need to write else. And lastly, if both of these fail, then we are sending the marketing email. Just by refactoring, now code is much more readable. This also reduces the cyclomatic complexity. What is cyclomatic complexity? Anyone? Cyclomatic complexity. Yeah. Correct. Number of parts the code might, execution might have to take. Basically, your code's cyclomatic complexity will keep increasing. And your aim should be to reduce the cyclomatic complexity, to reduce the indentation of your code. The more your code is indented, the more it will shift. Try to reduce that. One or two levels at the most. Refactor your code. If you see 304 levels, refactor it. A very simple thing to do. This is a class. We are updating something. We are destroying something, deleting something, and we are creating something. But the order is not correct. We are defining the method. The order is not proper. If you are reading this class, it is the first update. So make sure your methods ordering in a class is proper. We first create, then update, and then delete. Again, this will not affect the execution of the code. This is just for your own reading. So that your code is readable. Now, this is the big piece of code. No, this is a small one. If condition, we are checking one, two, and three conditions, and then starting the subscription. And these are all common conditions. User is active or not. User is deleted or not. Admin or not. So you can refactor this, put all those things in a function, and simply can subscribe. Then start the subscription. Also, note the prefixes I have used. Not user can subscribe. It is can subscribe. So this prefix is also important. Can do something. If yes, then do that thing. A big piece of code now. This is a function save. We are fetching some products from remote service. Then we are decoding it. We are running a loop on whatever data we got from this remote service, products data. We are inserting them one by one each product in database. And then we are also downloading the product images and saving it at this path. Basically, we are fetching products from a remote service and storing that information in our own database. Okay. This is one logic, one piece of code. A single feature. But don't write a big method at all. Your methods should never be more than five, ten lines. Try to stick to very few lines per each method. Reason being that makes your code, if you split your code into multiple methods, that makes your code modular and testable. You can test each functions separately. So let's see how we can make this code modular. So firstly, we were fetching something from remote service. So we'll create a function called as fetch products and we are fetching from that remote service and returning that JSON from this function. Then we were running the loop on that JSON object and inserting one product at a time in database. So we'll create another function, save products, run a loop, save it in database. And then we were running forage, can the forage allow a Japan look? We were running forage inside forage. So that was increasing the cyclomatic complexity. So what we did? The second forage for saving the product images, we extracted into a separate function. Save product images. And in that, we are running the forage to save the images on disk N as well as in database. And now the original method save, which earlier was quite unreadable. Now let's see how it becomes. Just this. And it is completely readable. You know we are fetching products and saving products. Now smart variable assignment, this is the last thing I guess. I will not bore you any longer. We are getting a user from database. If we didn't find that user then we are returning false. Else we are running some method on that user object. Now what does smart variable assignment mean? It means there is a variable assignment here and it can be done smartly so that we can save few lines of code. How? We can put that variable assignment inside this if condition itself. If this returns false, then this condition will be true and we will return false. Else we run some method. So that was all I had for today. I hope you enjoyed my talk. Please, if you like my talk, please follow me on Twitter. And this is I am Abbas Ali on GitHub. And one additional thing before I go, as I told you, I am primarily a Laravel developer, Laravel PHP developer. And I'm also very much active in Laravel community. And one of the organizers for LaraCon India, this is the official Laravel conference, national conference happening in Ahmedabad on 25th and 26th February. All the core people from Laravel framework development team they are attending this, they are attending this conference as speakers. So I will invite you all to please, if you want to learn more about LaraCon, Laravel, please do come. You can find more information at LaraCon in. And please follow us on Twitter again, LaraCon in. If you have your mobile in your hand, please go ahead and follow right now. Lastly, I run a local community, Laravel community in Nagpur called as Laravel Nagpur. And we run monthly meetups. We have been doing this since past four years now. Over 40, 45 meters have been conducted till now. And we make sure that it happens every month without fail. So if people are from, I believe most of you are from Nagpur. If I interested in learning more about Laravel, but it is called as Laravel, but it is basically all things around web development, be it PHP, WordPress, other CMSs, even other web technologies like UJS, ReactJS, XYZ, anything that is related to web development. We have talks and presentations on that and we have discussions on that every month. So please again visit Laravel in Nagpur, see when the next upcoming event is and try to attend the same. That's it. Thank you everyone. If you have any questions, please ask me now. Thank you.