 ok. Can everyone hear me or I need to be louder it is ok ok. Thank you everyone for joining the session today. My name is Rishita, me and my colleague Lynn will be presenting the session today to you. So, today we are going to talk about some of the coding best practices basically clean code. So, let us start our topic. So, before moving forward this will be our agenda. We will speak a bit on what do we mean by clean code, then some of the principles on how to write clean code, what are code smells, some common code smells and ways to refactor them, good practices more on engineering practices for cleaner code, then what next for you and some resources. This will be our agenda followed by Q and A and feedback session. So, before starting on actual content let me just clarify and set the expectation. So, we assume that most of the audience here are developers and a newbie developer and we assume that you have a basic understanding of object oriented programming. So, moving forward in the slides when I use the term classes, objects, methods you understand what that means and we would not go into too much of details into that. However, if you are a newbie and you find it difficult to absorb so many information in one hour, feel relaxed, we will be sharing the resources with you and you can explore more at your own pace later. So, that is our intent for this session and if you are an experienced developer you will find it as a maybe quick refresher for the clean code practices. So, and this is a very huge topic, it is difficult to cover it in one hour. Let us start. So, on a lighter note, how many of you can relate to this? Have you ever felt something like you are trying to understand the code and then thinking oh my god, is there a comment I can understand it better? So, this is a very common thing which usually happens. So, when you write the code in real business project we work in a team and the business requirements change very often. So, when you write a piece of code it is working fine that is good enough, that is not good enough, it is working beautifully it is ok, but there will be other team members who are going to touch that part of code and if they do not understand it over time it will become messy and over a period of time it will become so messy that the whole team productivity will just fall down. So, that is the reason we as a developers it is our responsibility to have clean code. Starting with some of the codes here it is not enough for code to work and by Robert C Martin and from Martin Fuller any fool can write code that computer can understand, good programmers write code that humans can understand. The reason I already explained because your team members need to understand the code which you write for to make it maintainable. Now, writing coding software like writing coding is a two step process. First step is to make it work that is the most important step. Once you have it working the next step is to clean it up. So, in real business projects usually what happens the developers tend to forget about the step 2 which leads to a messy code. So, that is why we all are here like there is a step to always remind yourself when your code is actually working now there is a step 2 to clean it up. So, let us see what do we mean by clean code. Now there is no such formal definition of a clean code, but these are some of the maybe like characteristic of clean code and these have come from what most of the pioneers in our software industries say about clean code. So, it is easy to read simple and clear small and obvious code covered by test it when you read through the code you feel like it is a well written prose it is easy to deliver new feature it is hard for bugs to hide written you feel like it is written by someone who cares and it has minimal dependency. So, the definition can vary from person to person, but you can consider these like main characteristic of clean code. Next, so how do we write clean code? Now, writing a clean code is an art and there are lot of principle techniques guidelines which helps you to achieve writing a clean code and today we are going to discuss mostly these four sections and the good part is the principles which we will be discussing our language agnostic. So, any language you might be working it is applicable to all of them and today's session these four I will be covering we came up with these four because we feel these are the most important and the most basic to follow ones to follow. So, let us start with our first thing the naming convention. Now, even though it may sound very trivial very easy, but this is something which is highly abused and just having a descriptive name improves readability a lot and saves a lot of effort for the developers because of the name itself is descriptive enough sometimes the developers might not go to in like if we have a function the name clearly reveals the intention no need to go inside the working logic to understand it that saves a lot of time because usually we will have a huge code with complex functionalities. So, let us say for example, we will be having lot of examples in the later slides and one more thing to highlight is it is these guidelines and principles are not casted in stone. So, everything has a trade off do what is best for your team or what makes your code readable the end goal is to have it clear and simple. So, always remember clarity is king. So, it is not that if it is written like do not do this do not do that you have to follow it what is best for your team what best best for your current structure of code you need to do that to make it to keep it clear and simple. So, let us start with our first convention always provide descriptive names and use intention revealing name. So, for example you can yourself identify which one would you prefer is int d and then writing a comment is that better to read or just elapsed time in days it is very obvious from here that the second one is much more cleaner and readable and other thing to highlight here the moment you feel like you need to comment it is it is an alarm that something is wrong the name is not descriptive enough that you are going to add a comment for it. The next one is like avoid temporal names like example a 1 a 2 these are not concerned because it does not reveal the intention of what do you want to do with it. Then avoid noisy words sometimes like you have a user array or a user table adding that array or table in the end does not adds any extra information or any value for the reader it makes it just more worthy. The next one is be consistent for example for doing the same thing there can be many words like fetch retrieve get now you want to fetch something from the API. So, have a be consistent in all your classes if you are fetching API then use fetch it should not be like some classes fetch some classes retrieve be consistent another example can be like some people in your team are using handle click in some classes some classes on click we should avoid that have a standard naming convention and be consistent with the names you follow. Another thing is again an example use pronunciable names from the code example itself you can identify obviously the second one is more readable and more understandable. So, even though you can like assume like MDH MS may be minute days hour something like that, but when you just read three lines of code you see that how much difference it can make and imagine if it is a very huge complex code having a proper name how much different it can bring and how much efforts it can save. Then avoid abbreviations for example the first one is not very clear now let us say here you have M underscore DSC what say you have P underscore DSC or L underscore DSC you yourself will have to keep track what does that mean. However, if the names are very clear you your mind does not need to keep track of all the variables and you can easily follow along. The next one is you name your classes differently and methods differently why because the classes and objects are basically designated by nouns the good example can be like it can be invoice product user these names are like good names for classes the methods must be designated by verbs why because the sole purpose of the functions or the methods are to do something we know that we write functions to do something. So, what they do their intention should reveal in their name for example, send proposal it is very clear pay taxes if I name a function proposal then you might not know ok what this function does you will go inside the function check what it does if you name this function as proposal or let us think about send proposal to be approved this name also is not very accurate why because the function might be like I am sending the proposal for getting the approval it might get rejected also there are 2 cases approved or rejected, but the name says to be approved it is a bit vague not very clearly identifying what the function will be doing. Next we will be ok that was all for the naming convention and stating again that is not an exhaustive list there are lot many guidelines and rules, but since we have 1 hour session we try to pick only the important ones what we felt was more important. The another topic we will be discussing is object and data structure. Now towards writing cleaning code this is also one step you should clearly understand the difference between your objects and data structure when should you use object when should you use data structures. Now objects are something like they hide their data behind like abstract their data and only expose their functions and the sole purpose of data structure should be to expose the data while it should not have any meaningful names. I will show the example of an object and data structure usually in the code we see what happens is when the developer is confused and they mix up. So, some structures are half object and half data structure it makes it very difficult to add new changes later. So, it is not a clean code when you mix the data structure and object together. So, the rule is always hide the internal structure of your object we should be telling it to do something and not exposing the internal implementation of it and for that reason be always mindful when to add getter and setter. So, usually developers might be adding getter and setter for every of the variable which is not a good practice and there are some data structure like data transformation objects and active recalls and the sole purpose for them is to communicate with the databases to pick up the raw data transform it and expose it to the code for being used in other classes. So, we should avoid adding any logic to the our DTOs and active recalls to have a more proper understanding. So, now here you see the first one is the data structure why because it is not exposing any behavior it is exposing only its data it does not have any behavior only data and on the other side is an object. So, you see the data is like the private variables it is not exposed outside what is it is exposing is its function it only is exposing its behavior while the data it is working on it is completely hidden. So, this is an example what is your object and how this side is the data structure and when you have a data structure do not add any business logic to it this is like what clean code says to have a cleaner code and now to achieve this like hiding internal structure of your object there is a principle called the law of demitter or the principle of least knowledge. So, what this principle says is a method of a class C should only call the method of class C in object created by F or an object passed as an argument argument or an object held in the instance variable of C which the meaning in very simple terms would be talk to your friends not to strangers and talk to only your close units. So, in the diagram also you can see a communication between A and C is discouraged the diagram like it violates the law of demitter. In terms of example, if you see the red block here the CT XT context is an object. Now, I mentioned the to have a cleaner code we want our object to hide its implementation details, but here you see there is lot of dependency and there is lot of information we are exposing. However, let us say CT XT the context is a data structure. Now, the sole purpose of data structure to is to expose its data. So, if it is something like that that is ok because its purpose is to expose the data that is fine, but if it is an object following this coding style is not a good one and it will be it will lead to messy code later on. So, let us think how should be the good thing. So, let us say the requirement is we want to create a new file and for that we want to get the absolute path and here I am not showing you the complete code the idea is just to expose the thought process behind this. So, now if say we want to achieve it one way is to think is ok get the absolute path and then do something and create file or we can have something like this. Now, obviously the next one is much more cleaner because it is not exposing anything it is it is hiding all its implementation detail. So, it always depends on the requirement and what do you want to achieve mostly how do you design your code maybe. So, if you always want to hide the internal implementation for an object this was about data structure let us move on to classes now. So, the classes are the building blocks of our code and since building blocks what will you prefer to build something you will prefer small blocks rather than the large units of blocks because smaller blocks gives you more flexibility. So, what clean code if you want to achieve cleaner code the classes should be small the classes should be responsible for doing one thing and that can be achieved through single responsibility principle. Things that change together should be placed together and unrelated things should be kept separate. So, classes should maintain cohesion the classes we write should be prepared to allow changes because changes inevitable. So, some principle which help you achieve that is if you follow open close principle and we want our classes to be isolated from change the principle that helps us to achieve that is dependency inversion principle we will be looking at these principles with some example, but why do we want our classes to be small and organized. So, what do you prefer you would like to have organized tool boxes with small drawers with well defined components or do you want few drawers with everything tossed into it which one will you prefer. Obviously the first one right it will be easy to manage when we have the small drawers with well defined components. So, the idea behind organizing our class is to keep the classes small and organized. So, let us see the first principle which is single responsibility principle. So, we say that classes should have one responsibility and look at the picture which one would you prefer the first one is a big class doing too many things the or this the below one which is each class has its defined responsibility and each one is doing its own work not dependent on others. Let us say if I want to change the cooking structure cooking instructions. Obviously making any change in the above diagram will impact the other works because the same entity is doing all the task. In the second diagram what if I want to change the cooking instruction I just need to bother the last one who is cooking the other classes can continue doing its job no impact on others. So, like this is what in the picture form we want to achieve we want small organized class and for that we have single responsibility principle which says that every class should be responsible only for one thing there should be only one reason to change that thing. Another thing you can think of is if you cannot come up with a concise name for your class then something is wrong. Let us say in the name if you have some if and or it is a clear indication that your class is doing more than one thing or if your class name is something like manager processor super it is also a clear indication that your class is doing more than one thing. So, let us see what do you think about this class now this class I have just taken a snippet this is only half of it there are lot more up and there were lot more functions up and down. So, if you encounter this kind of class you can think what how difficult it is to make any change or any amendment here. So, usually this kind of class is referred to as a god class which is like doing all the things doing everything. So, we we do not want this kind of code this one of classes in our code and what we can do for this if you encounter this big class the first step should be extract out smaller classes from it. So, from this you can see the the three I can easily identify that get project first project get last project this is it is it can be extracted out into the smaller class and this has lot of scope into extracting into smaller class. So, whenever you have like this big class that is that is a alarm that ok something is wrong you should not have this big class. Moving on to the next thing is maintain cohesion. So, we see that our classes we write should maintain cohesion to keep it small. Now, what do we mean by cohesion now this is an example of a class here we have two variables and three methods. If you see the three of the methods are highly dependent on those variables. So, these two methods are using all the two variables the first method is using one of the variable. So, here we see that the methods and the variables are highly co-dependent. So, this is a example of highly cohesive class let us say another example of less cohesive class let us say you have four variables and two methods. So, the green variables are being used in the green method the orange one are you being used in the orange method. However, the green one has nothing to do with the orange variables. So, this one is less cohesive and this one is in clear indication that there is a scope of breaking it into two separate smaller classes because this is less cohesive. So, when you try to maintain cohesion you will end up having many smaller classes and that is the intent of clear code clean code. Now, when we write our classes we need to be prepared for change because change is inevitable. Now, let us see an example if we have a class something like this SQL which have certain behaviors if we know that this class is going to be changed very frequently. How do we ensure that when we add new features here the existing features do not get impacted and if this class is a very volatile one we need too many changes very frequent changes we need to do something about it to every time ensure that the existing functionality did not break. So, how do we ensure that? So, there is a principle called open close principle which states that the classes should be open for extension but closed for modification. So, what it means is we organize our classes or write a code in such a way that when we add new behaviors we can easily extend it, but we should not be touching the existing code. So, let me explain it with a diagram view if we organize the same classes in this way. So, what we did was we just in introduced an abstract method and then each of the functionalities have is created as its own class. Now, this gives us flexibility in future we want to add new items we can just add the new classes without really touching the existing ones. So, we are very sure that we did not touch the existing classes the there will be no breaking in the existing functionalities and we can easily integrate our new behaviors. So, this is one way of ensuring that the existing functionalities do not break and this also leads to many smaller classes. And moving on to the next one how do we isolate our classes from changes? So, we do not want our classes to be rigid we want it to be flexible. So, how there is a principle called dependency inversion principle. So, the one you see here we have a class A which is depending on the concrete implementation of class B. We do not want that because every time there is a change in B it will impact the A because it is directly dependent. Now, what do we do to isolate the changes of B from A? So, we can introduce an abstract layer by introducing an interface. So, the flexible the green diagram we you see we do not directly depend on the concrete implementation of class B instead we are depending on the abstract implementation. So, now any change in class B will not impact class A even though they are dependent. So, let us see an example let us say we have a portfolio class and that depends on stock exchange. So, now if the stock exchange keep changing our portfolio also keeps changing. So, how can we avoid that? So, following the dependency inversion principle what we can do is we can introduce an abstract layer. So, instead of a concrete stock exchange class we create an interface and that whichever functionality wants to implement we can extend it and pass it as a constructor or constructor or something and this is how we avoid the direct dependency on concrete implementation. Now the portfolio class depends on the abstraction of stock exchange and any change in stock or let us say you are writing a test you can easily write a test for portfolio because now the stock exchange you are not directly depending on the current price. You can just mimic the current price in your test and that is how your class is completely isolated from stock exchange concrete implementation. Now this slide we have because we decided when we are talking about clean code and not talking about test it is incomplete to bring up test. However, this is like just scratching on the surface it is a very huge topic, but we just wanted to ensure that we introduce this to you. So, now test code is as important as production code. Usually we tend to ignore the test and do not clean our test, but it is as important to clean our test as much as we clean our production code. So, why should we do that is because test gives you the actual confidence to make changes to your production code. If your tests are not clean eventually the test will rot and so will your production code. So, it is very important to keep your tests clean. Some of the like rules for having a clean test is following the first rules that is fast, independent, repeatable, self validating and timely. So, what this says is your test should be fast, it should run very quickly. The reason for this is if imagine your tests are running very slow and the developers need to run the test every time they make some changes. If it is running very slow they will be very demotivated it to run very frequently. So, for that reason we want it to be fast independent means the test should not depend on each other, repeatable in any environment for example, QA or staging the same set of test can be repeated. Self validating that means it should have a Boolean output like either pass or fail no other manual interpretation of the results or something. Timely like we should be following TDD it should always be written before writing the production code. Now some of the things here are already taken care by the latest test frameworks, but as a developer like when we write test it is our responsibility to keep it clean like single concept per test. We should not write test with like too many assertions in that for example, if you want to write a test for approving something and notifying something. So, your test should not be should approve and notify. If you have something to test like that it should be should approve should be in one test and the notification feature be tested in another test. So, basically your test also needs to be clean. Consider your test give your test the same weightage as you give to your production code. Now next we will be covering some of the code smell and for that I will pass on to Lin to continue on the code smell topic. Thank you. How is everyone doing? Stay can come with the other session. We have a few chairs here also like if you guys want to be move along or like there's some empty spaces here also before we start. Yeah, there's some few chairs behind also. Okay, are we good? Shall we start? Okay, what is code smell? So, literally they don't smell but definitely they can stink. So, let's talk about what are the code smells. So, the code smells means that there is any symptom in our source code. Probably they are indicating about that there's a deeper problem. They are not technically they are not a bugs. They are not technically incorrect or they are do any prevention from program for functioning but they are usually like weakness in design and implementation choice that could hinder for us to be further development and also maintenance also very hard to evolve our code and also as a result it could also increase the risk of some failure and a defect also. So, bad code smell could be also an indicator of the factor that contributed the technique at that because of the poor quality of the code is written. So, if you have a if you want to change a some code in a one place right, you have to change in many places and other places too. That means that we have a code smell and usually even those we learn about all those clean code and all that technique and the principle right because we are working on the very tight line or like there's no good engineering practice or sometimes like we don't have like you know good code review or like we missed some code review. This code smell could not be inevitable. So, determining what or what is not a code smell is very subjective. So, it can be very by the like language and the global and a methodology also but from this session we have covered for some of those common codes smell and we will see as some of the way how to refer to them. So, let's start with the first smell. Duplicated code. So, duplicated codes like they are like identity care or very similar piece of code or can more than one places. So, in a buff exam he also write we have a two method one is called the is pass another one is passed with credit. What do they do? So, we got the sum marks from the student and then calculate the average and checking. So, they are exactly the identity care just only the one line is different. So, this is also a sign of the duplication. So, sometimes also even those that cope may look like not exactly the same. The duplication also could be occur. They are performing the same job. So, there might be some cope with the different method name, different implementation but they are doing the same thing. So, this is also a duplication. This is a sign of duplication and usually also like when we are working on the same project with the cross team and we have a lot of communication and a paper time to produce a same code over or over again and again. So, how we can refer to this kind of duplicated code. So, from here right this code and this code are duplicated. So, if there is a duplication in the same class what we can do is we can extract it into a new method or if there is a duplication in different classes we can create some class hierarchy. If there is some duplication occur in some child classes then we can put it into the parent class or super class. So, from the above exam also right we create another private method to calculate for the average then we don't need to duplicate it anywhere and the one good thing about this refituring is our method also began as shorter and easier to understand and easy to maintain and more over because we make centralize all those like code duplication in one place right if there's something need to be changed we only have to change it on our private method. We don't need to change on the two different places also. Okay, next. So, this is very very common also like when we start writing a code right like as a double bar also we try to be like very futuristic. So, we always put some place folder for the future requirement. We always justify like yeah we might need it for later but in the end of those classes like nobody use nobody care also nobody maintain and then some of those classes like like some interface or abstract classes they are only implemented by one class and they even have a chance to live once probably called by the some task method or task class only and like those classes also right we tend to add on a more feature or more implementation getting forgotten buries and then loss in a documentation also. So, this exam here we have an abstract address class and we have an interface to implement some logic and we have a home address extent. So, from the exam method I can justify like yeah we might need it for address office address that's why that's we have an abstract and we have an interface. So, this is a sign of the cosme also do we really need it for the like those abstract class and our interfaces actually know right. So, how we could refactor this kind of cosme. So, if we see this kind of cosme right if we see there's some end use abstract class or interface we can collapse into hierarchy if there's some unnecessary delegation of the functionality to another object we can maybe put it into the inline class or we can use the inline method and totally remove those end use parameter feed or method these are they are just noise in our code base only. Just rule of ten is like create a code for the current requirement nothing more nothing less. So, from the above exam after we refactor right we can totally get rid of our address and interface it's no longer necessary even though we need it for the office address we can instantiate it from the existing address class okay next. So, this is like one of the very common cosme in everywhere. So, this we have a like this checkout method and it's doing a lot of things this is like one of the client code violating the client code principle also it's doing more than one job. So, because of it's doing so many things right we have to put in the common also to understand about which session of code is doing what. So, and also there's no clear cohesion also there is it's very hard to understand why do we need to this checkout method is like doing so many things like so many jobs like calculating the total price calculating the delivery fee and also storing the database also maybe creating some object and return or something. So, how we can be understand about this kind of a cosme right if you are writing a method and your method is too long people tend to like subject like you know how many line that we should be inside in the method. So, most of the people agree is like it's more than 10 line we should ask a question is it this method is doing this one thing or like doing the many things okay and usually what could be happen is of course no one intend to implement this kind of long method right we tend to add more thing because we are adding more feature or more implementation. So, usually this kind of class this is kind of cosme are like large class or long method. So, how can we refactor that one if we found this kind of long method we can be extracted into the smaller methods for large classes also we cannot split into the smaller class and it create a hierarchy for those common logic. So, above right for checkout method of course this is just one level of refactoring only we cannot be put it into the private method for calculate total price calculate delivery fee. So, we don't need to be like putting so many things inside our checkout method and a good thing about here also it seems we use the semi clinical principle of the like naming convention and descriptive name we don't even need to write a comment by checking here we can understand like this checkout method is doing calculate the price delivery fees update db and so forth and so forth right if someone don't want to interested what is the implementation they can do the individual private method and sc okay and now one of those good thing about this refactoring is it can also help us to avoid duplication also because we isolated those logic and a code into a different smaller method okay next cosme slown parameter list this is also similar to the previous exam also so usually when we are adding a new function or when we are adding a new feature we might be in turn off we are considering for the good design and a code consideration we might be adding on the existing method and like it ended like having a so many parameter list and also it could be possible because of the sums method multiple methods are merged into a single method so that's why that we meet we need so many parameter list one good rule of thumbs is like if we need more than three parameter right we need to ask do we need all those parameter for this method implementation if yes probably we might be any have a long matter we have to consider how we can refer to it okay and also this kind of long parameter list method are very hard to understand hard to change also and even hard to reuse so people will be afraid to call this method from somewhere else even this slide want to get the formatted address or get the order because we don't know what is why do we need so many parameter in the first place so how we can refer to this kind of long parameter list one way is those group related parameter together and introduce in the parameter object so from the above example right instead of passing down all those string value for formatted address then we can pass the address object is less less parameter and do the same job also same for the below example also to get the orders right this is kind of like a look like that is query the data from the maybe order table or something we can create the query object so put it all those like related information into the one class then we can pass it down into our method so there's another way also it's like we can also replace the parameter with the method call if we follow those parameters as a result of another method call instead of passing down getting the result and passing down into the separate method we cannot directly use the method call and we can also preserve the whole object instead of passing down from the group of parameter okay and also benefit of this refactoring is is shorter it's more readable yeah next one so this is called is a primitive obsession so why did this this is a very bad practice of using the permitted type to represent the domain object so from here right we have a customer class with the name email unit streets city country post echo and blah blah blah so it this kind of code also the one of the disadvantages is they could tend to grow in a number of primitive along with the behavior so if we need it for let's say office address are we going to add a summer other variable here related to office address and it could be get worse when this same primitives are need to be defined at different places we will be end up having a duplicated code so how could we refactor this kind of thing very simple create a class to represent those related together and also move along with the behavior it will be give us a more flexible to use the object instead of using the permitted type and also bring us a more cohesion organization to the domain level so from the above example right instead of using all those string value we create the address class then we can make use of the address class in our customer okay next one so this one is data club so data club is like piece of data found in a many place many part of the our code base when they can be related they are seems to be related together they doesn't make sense in isolation but only make sense together so how we can do that this kind of data clam right if you want to make sure whether we have a data clam or not just delete one of those part of those of the data value and see whether they as they make sense so in an example there's a two example right for the apply leave to apply the leave we need a front and two right if we remove the one of those it doesn't make sense this matter is doing nothing and for the booking also to make a booking we need a like customer name guest name or passport number passport issue day passport expiration date right if we remove one of those value it doesn't make sense if this matter is doing nothing so how could be refer to this kind of data clam group those like data together into a class and introduce the parameter object so instead of passing the two many parameter right we create the data range as a class and passes as a parameter object same for the booking also we create the guest info class and pass it down and also issuing the parameter list and it's also much cleaner to see right the next one is nested condition so the nested conditions like this is very common also like in our code base right there's a so many layer of if a statement or sometimes switch statement also so why do we have this kind of nested condition it could be possible as like maybe initially we just start with a very simple conditional checking and we need to add for more feature or maybe we need to fix some defect then we end up having so many nested condition so these nested conditions are very hard to read hard to understand hard to maintain also the deeper the nesting the longer it will take us to refer to so there's a few techniques that we can use use a tannery operator most of the modern programming language support tannery operator so instead of we are having an if statement use the tannery operator here to do for the same logic and same thing and also it's much more cleaner instead we have a four line right we can end up with the one line of code and our next one is a simplified condition so what is this doing is like this total quantity is greater than 50 we set it to some value to true or false we cannot put it into the one line only why do we have to do for the nested of course this is just a some exam only but in reality right there might be a many layer of like if a statement that we have to go through right next technique is we can combine those conditioners also so this is also very common one like we have so many layer of a statement and it might be analyzed we only have one statement so why we cannot combine those conditioners we can use an or or operator to combine those nested layer it will be much more cleaner much more easy to read also and the next one is we can use a guard clause to exit Ali so here is the exam is if the quarry is not now we want to do something right we can think about the other way if quarry now what we want to achieve so we try to exit Ali before we go into the all those nested now and just be aware that everything must be in a moderation don't abuse so even if we suggest to use for those kind of techniques and all those things right the below azimuths are very hard to read what is this doing there's a very there is statement with like not a and b or c and d i even coordinate differentiate like what would be the output of that one i'm saying for the tannery operator also this is abusing we have two level of tannery operator okay so try to avoid this kind of things and less but not least so for the cosmer we cannot talk about we cannot end the cosmer without the bad comment so bad comments are also like some piece of a call they are not says explanatory that's why that we have to put a comment in the first examer right what is fdf history we don't know so that's why that we have to put a comment why we cannot use the clean code techniques like use the descriptive name then we don't even need to have a comment and the second called second examer is like to do this is very like most of the developer also tend to do we are writing a the comment should not be on your reminder if you see this kind of do-do thing we need to take it and we need to check why do we have to to do to do comment is it we cannot do it at the moment or something is blocking us if we can this kind of to do is like at a unit test why you don't write a unit test in the first place why you have to put for the reminder and the second uh and the third examer so this this test that examer also is like do something big we don't know what is this method is doing that's why that we have to put the some description on the top of the method so when I was preparing for the slide I just want to make a joke so like this method get the item from db watch dishes take a walk blah blah blah so we don't even know what is doing so you know one of the sign also this is doing so many things and we don't understand if we break down into smaller method we can totally get rid of those comment and unless best not least some of the code also we cannot put it for the um we have those commented code okay why do we have to comment it out code that's we are using a source control system right why do we have to use a source if you the code are no longer needed why we cannot totally get get rid of from our code base so it will be much more cleaner also and also if you see this kind of comment code right usually people will also tend to forget also and they also afraid to delete because oh my someone is do this like maybe there's a some meaning behind so it's very um very very annoying okay that's all for the um cosme there's a many cosme that we haven't talked about in our session because of a due to time limit but I hope that that that you guys understand about the some of those common cosme and how we can refactor it and can be produced a better code so the next is some good practices for the um cleaner code so we have come up with a summer idea what should be the good engineering practices to write a cleaner code okay usually right we don't always get a chance to start up from the clean state many time and most of the time also we are working on the existing report and it is very important to clean otherwise very difficult so first thing is remember about the be mindful about the wise cop rule leave your code better than you found it so even though the code is clean before you you found it and then you must say that that is like your responsibility to clean it clean it also and what we should refactor is every time remember to refactor next one have a summer good engineer practices in place so have a good regular code review not everyone is perfect even the senior deaf also could reproduce a bad code and a cosme when we are rushing for the some delivery or some type um timeline right so we can detect all those cosme during the code review so don't skip the code review I mean like I have encountered sometimes also like in a project right when we are rushing like people say oh let's skip the code review and then push the code okay and next one is like people are scared of refactoring because they are afraid of breaking things so if we have a good test we will it will make our life easier we can have an ease of mind to refactor the bad code from the clean code if we have another test so you will know you break something if your test is fake so try to have some some uh good um practice of the uh having some TDD or like test code and test method and last but not least leverage the latest tools and plucking so most of the IDE right we have those refactoring functionality instead of like manually deleting your code or like putting extracting into the different uh method or class try to use the existing IDE functionality there's a lot of function for refactoring most of the um IDE supported so we can also leverage the using of like you know checking for some safety check like this code is used in which places and so far and also some of those um very good uh well known um code analysis do is a sonar queue sonar queue is a static code analysis too it can give us like a what is a code quality of your code and also can provide some of the recommendation also okay how to refactor and uh how to improve your code quality so that's it what's next so if you want to practice more on those clean code and uh to practice more on the refactoring and like understand about learn more about the coltsman and everything we want to recommend first book from the clean code by the robot c martin and get this should be one of the handbook from the author software developer then the next one is refactoring book this is from the martin fowler so here it shows a lot of techniques and rules like how can we refactor and the next one is this is a git report you can download those you can go to this git report and practice to refactor the code also that intention of this report it is written in many languages so you can pick at which programming language that you prefer that intention of this git report is they are intentionally right in the like bad code so your main responsibility is to refer to okay yeah this is some of the resources that we use it in our slide and question and answer any question any comment any thoughts any sharing yes um we will share this slide also right yes yes yes so this one is a very popular cutoff to especially learn the refactoring part i would highly recommend it go there and one thing if you really want to learn don't look into the solutions there are a lot of solution available on internet don't directly go and watch the solution videos or the blocks try try it out yourself try to understand there is the business requirement explained the code is intentionally kept bad try to refactor it like it's really good thing good learning if you do a practice on this cutoff highly recommended any other questions any comments suggestion yeah so um this is like we are just giving a some surface of the idea only so usually like most of the organization i guess sona q is using for the code quality improvement um it's also not very cheap so far what i know uh and uh some of those like refactoring functionality right regardless of which id that you are using there should be some basic function of the refactoring like extra method extra class of like you know create parameter or whatever that should be keep on using all those kind of things instead of like manually copying a piece on the different places because definitely if you do manually something might break also your code may not be like a lie and some this is es links is usually most of their front end developer used for their javascript formatting everything it's also recommended there are much more also we just give some idea and an example here only yes sona q support that so if you run the usually most of the enterprise project like we have set up for the sona q report and then whenever people start checking the code right sona q will automatically run there i i know that there's some plugin available for sona q also you can use it in your id level within your project level or whatever because it will be quite huge to scan all those like the whole code report right but usually most of organization level we do for the sona q when you check in at the some code sona q will automatically run it will give you if you have set up for some notification also you can i get some kind of like how many um you know issues or like based on the um severity level like what is a critical issue what is a major issue high issue and they can also provide you some recommendation also those duplicated code where is duplicated which line is duplicated so far and so forth any others if you're using an open source project you can also use something like code requirement yes yes of course this is very common question right so like yes um you can recommend of course may not be get approved for sure also uh another way also like since you have no about how to write the clean code and what is the cost may arrive you cannot keep on practicing also even those like you are just newly joined to the project you are very junior also you can suggest like maybe try to get practice get keep on get more practice and try to influence other people also so maybe you start with your colleagues that who are you trust or you you you cannot you know talk or share or whatever at least like i feel like most of the case right code review is a very good approach because nobody's perfect even like you know people will be tend to forget all those principles and a good practices so have a share review within your peer or like your colleagues and like you can also suggest to your senior like or maybe if you are not sure also you can check with them why this code is too long why is written in this way is there any way that we can improve you can suggest also just uh just to add on so there is something called tech depth so there is always a trade-off and we understand that sometimes the business is hurry to deliver so the internal quality of code sometimes can get ignored but there's always a trade-off like uh you want to pay less now or you want to pay more later so the more you uh ignore your tech tech depth so as you mentioned it's one year so either you start working towards it and later if you if you say you want to improve it after two years it will be much more costly because the code has become much more messier so the phrase that goes on pay less now or pay more later so which one will you prefer so you can always like encourage the team to get on the good practices and like keep track of your tech depth so even if we can highly understand that in a real business it's not every time we don't have the super clean code it's okay we but we don't ignore it we keep a backlog of it and we will work on it later so you can try to follow that thing like yeah pay less now or pay more later don't don't forget to clear out those tech depth also like don't keep on adding and like forgetting to clean those tech deck yes any others thoughts comments yes yes yes yes i think it depends depends on the which line that you want to go for approach so like even those read it did and like functional also right there's a sum of the rules and principle can be applied applicable even for functional programming or ob programming and also you of course there might be some kind of like certain principles rule only can be applied applicable for the functional programming so maybe if you want to go for that kind of journey you can learn more and i get on practice so sorry like i don't have any clear answer for that kind of question yeah even i don't have much knowledge on that but one thing i can explain you in a similar context let's say we have microservice architecture and because it's a fancy everyone running towards it so like everything tends to solve a particular problem so you need to decide what problem are you solving so the object oriented functional programming there is a particular problem they both are trying to solve what kind of problem you want to solve so like i can explain more on microservice and monolithic for example now the microservice is more fancier and everybody is doing it so everybody kind of rushed towards it but that's not a good thing to do try to focus what problem you're trying to solve and there might be simpler solutions for that so in this context as well so object oriented or functional or reactive like the front end react you need to identify what type of problem and whether the solution you're choosing it focuses on solving that kind of problem or not rather than whether it's easy to test on or that's not the criteria to choose the language i think it's depends on there not on the programming language i think it's depends on the depth whether you create a cleanup code or you create a messico is up to you only the programming is just just just a tools to write the software solution solve the problem yeah so just to add some more context now these programming languages are again created by some human who has some intention in his mind just for an example when i was going through how to write a clean code i said do not expose like getter and setter be mindful but in java beans by default you will have a getter and setter for all the variables so each thing has a different intent like it's your responsibility to use it wisely to have a cleaner code so certain languages like there the the programmer who built it had certain things in his mind certain focus in his mind and that's why it's built in certain way it's it's not like this language is much cleaner this language is it's not like that as a developer it's your responsibility to choose the features and to use its characteristic in a well proper way so that you achieve a clean code yes yes true yeah so usually one thing that what i can say is like you show the business what is the value of the clean code like we have explained right like down the road also at the end of the day your code will be very messy even those like they want to deliver they want to push us to do the some delivery also they couldn't achieve because of the code are very messy a lot of things to be referred to a lot of things are broken one we integrated together right yeah yeah we actually had a diagram we wanted to include that but because of time constraint we could not so usually to explain this a bit we we highly yeah this was the one so there are two things external quality and internal quality so for the business showing that external quality is good meaning your user experience and the number of defects this is your external quality and business can understand they will focus on improving the external quality but your code quality is like something internal and as a developer you can understand it and it's not so visible to the business but it's more of a mindset and it's our responsibility to convince our business that this is equally important now this is from martin folers website so usually let's say we are starting with a fresh idea we are create like a startup thing we try to deliver things very very faster so the yellow line you see is of low internal quality so initially the time to deliver is faster however if you try to maintain high internal quality initially you might feel that you are slowed down but after a certain point and that is in weeks not even months you will be much you will be able to deliver and our productivity of the team will be much higher when you have a higher internal quality so it's more of convincing the business as a developer it's our responsibility to convince them because the business people cannot see the internal quality it's us who are able to visualize the internal quality so if we want to keep delivering faster we need to maintain high internal quality that's i hope that answers any any more questions yeah so usually for those junior like i mean one way that what we practice is like we have some kind of pay programming this is one way that we cannot practice also either like you are less experienced programmer also like you know you can pair with those senior deaf then you can learn about more about the business and also like some of the good practices and some contests also so this is what we are encouraging but of course like maybe some organization also the pair programming not usually practice and very expensive to practice yeah so yeah so i completely agree with lin and just to add on top pair programming is the solution for that but if that's really not possible given your current context so maybe take small steps when you have a very big complex code usually you will find that the 20 percent of it comes like the 80 percent of the actual logic comes from 20 percent of it like the Pareto principle try to focus on understanding the most the most frequently used part of code once you're able to get hold of that slowly you will be able to understand more so i'm not sure if that's the correct name i think it's the Pareto principle so 80 percent of the value comes from the 20 percent of the code something like that so try to identify which is of the like since it's very huge and very complex take a small step and identify which one is mostly used and start learning small on it or let's say one thing you can do is if there are not tests you can start writing the test from my personal experience uh i was working on a code and it was really complex i could not understand there was no test also start writing tests for it it will give you a lot of confidence in terms of understanding the code and also the change you are making you are very confident that your tests are there to back up you like if it fails you know what fails so you can start like take a first step towards it maybe in your team encourage people to start something towards writing test yes please uh we can use like to do comment so we have to i just give some some you know exam and like make some joke here only so if we know that that to do to do common is like you have to write a unit test right why you don't study in the first place is like you are violating one of those rules already right and another thing is like the comment is not bad we can put the comment sometimes the comment can help for the some um you know developer who are not familiar with the system or how the things are doing it but usually right as a developer most of the time nobody read those comment we just did dive into the code and then check what is doing and what is this function doing what is this class is doing right so why we spend so much effort on writing those comment which is those are very obvious maybe it's a very very important information that you want to deliver you can stay write the comment but i grant you like 90 percent of the death are like just start looking for the code just to add so to do comments are not bad comments they are considered as good comments but what what we want to avoid is don't get in a habit of writing to do comments one to do one or two here and there it's fine acceptable but don't get in a habit of i'll just ignore it let someone do it to do i'll add to do everywhere okay write a test here do this do that you are like take step to refactor like you can spot something and if you want to refactor do it yourself if you don't have the capacity we understand we need to add the to do but don't get in a habit of adding it every time like too many of to do is wrong to do is a good comment in itself but too many of it is something messy yes any other thoughts sharing comments yes please do you mind to share more a bit like how do you usually you usually also write like you can also think from the light like recital share also stuff from the small step so even those like you know that they're very messy code what you want to achieve you will be adding for maybe one or two function or like doing something of course the existing code with the very long method or long parameter laser is very hard to start writing a test and most of the time also people tend to like forget about the test and then just add the code right so but if you know that maybe there's a small function that you are adding there's more feature you can understand test why don't we start it just to add on so if you follow tdd you write test before your production code and that's much easier to do but if you're writing test for an existing code it's it's much much difficult to do so how to start like i'm not so what i understand is usually you we write like characterization tests so for an existing code when you write you tend to just follow the code like the test will pass so that you understand what the code is doing from your test once you have the characterization test you start refactoring like let's say you have a big function so just don't jump into refactoring first write a test that's already passed on your existing code now there is a test to save your back so if when you start refactoring now you know that the test will tell you if you messed up something so just write a test and maybe that test can be uh how do i say it i'm not getting the correct word for that but maybe you get some kind of safety net like something broke yeah your intention the first step should be to get a safety net then start refactoring and don't forget to refactor your test as well the same principle so if you remember the dependency inversion principle single single responsibility those are all applicable for your tests as well so yeah experience writing like uh working on it legacy code right i'm sure you're talking about legacy code there so i guess if legacy code usually the first thing i'll do i would have done would have been to write unit tests to cover that function but usually with legacy code there's a lot of spaghetti code and there's a lot of entanglements and a lot of dependency already in that function which is which also lets you let's you understand a little bit better why the function is like so badly written right but if we can figure out right the test coverage for that one function right along with all the dependencies all the needs and you can go proceed to refactor slowly uh since oh okay now there's too many things being entangled into this function maybe i should break it up and helps you reorganize the code better as well along the way yeah so start with uh test coverage for at least the existing functions there's no test uh then you make then you make uh the update the test to introduce a new new feature of behavior and then you try to introduce a fix uh introduce a new behavior that's one of the ways you can try yeah there was one more slide we added for that i was looking for that but we have skipped it i'm not sure if that can come you the approach we should take there were like list of approaches uh i i'll try to get um okay i think i think i close it it's really difficult to come up in one hour for clean code and code smell we wanted to cover a lot of things but we decided to cut down kadoom and yeah this one is like uh ensure you have test for your existing code start writing test for your existing code so that it has it has a safety net then you should start writing test for your new feature and pledge that whichever new code you're adding you will have a test for it before you start writing the code uh yeah this is like the cycle that will be followed any others yes yes that's also good approach and uh yeah so we will be taking on more questions meanwhile we will be it will be very helpful for us if you can have submit the feedback for us and meanwhile meanwhile we can continue q and a so if you have any more questions it's very interesting for us to hear and i guess everyone is hungry now also yeah let me check with kevin do we have more questions uh the previous slide this one no the links a few links uh okay yes do we have any more questions yes yeah as mentioned like a certain programming like i i may not be very uh expert on answering that but from my experience what i can tell you is it's not that language gives you clean code you need to identify which features went to use for what to use as mentioned before like we say that avoid adding like exposing the private variable avoid uh adding getter and setter for your variables but java but java has it beans where it allows by default the getter and setters so js doc also has certain features for certain problems try to use it wisely and that will result in a clean code it's not that js doc promotes cleaner code every language has certain features it's it's your job to choose wisely which one is for what type of problem in terms of energy efficiency i am really not knowledgeable on that but uh anyone else can answer that in terms of energy efficiency clean code for AI projects yeah thank you so much for the answer i i hope that really answered yeah so even yeah thanks a lot for sharing that mm-hmm it depends on uh okay it depends on your passion like do you really want to do it like i think it it really depends on you if you have a passion you can easily learn it so nowadays the coding like you might feel it oh my god what is it but with time it has become easier and easier the languages have become much easier so they are here to help the developers it's it's not like it's it just depends on you how much you want to learn how much you want to do but there are a lot of languages and to start with i would suggest you can start with javascript i mean that's very the common language how we speak the english language format the other languages are also not so difficult but maybe for starting point i i can suggest maybe start with javascript and then uh you can move on to something else but trust me the languages have become easier more human friendly so it's not that big thing anyone can learn to code now and you just need to find the right forum and right resources that can help you i hope that answers uh you have a lot of udemy courses like in in internally thought works we we follow the udemy platform you have plural site you you can join conferences like this and i would prefer like i would suggest don't do it alone find a buddy who is someone like you trying to learn and that is much more helpful uh join some like he mentioned developer jim or something those kind of events join them that will be helpful my answer for that would be stay in that project for long because you are there when you are creating it you are not there when it's failing so if you really want to hold your horses stay there for longer and see how it fails as he mentioned developing is 10 percent maintaining is 90 percent be for the maintaining phase then you will really understand the pain points and then you will never try to jump on the next feature without cleaning it up so try to experience that pain stay there for longer maybe with that project which you created so yeah that would be like because usually developers like if you don't experience the pain you will not clean it up maybe because you haven't experienced the pain yet or the people around you haven't like come and shouted at you so be like be like acting more professional let's say not for developer let's say a plumber come to your house he knows all the bit and tricks you ask him to fix your tap or something he knows that doing this will will do it for now but maybe 10 days later it might not so if he fixes is just for 10 days and goes away are you going to call him again like you realize every 10 days it's getting the same problem are you going to call that plumber again no right you will start looking for another plumber so it's same kind of thing with the developer we also need to be like have some more professionalism and once you experience that pain definitely you will start working on the clean code and apart from this mostly how like I have experiences there are code reviews because some like senior or someone is going to do that code review in my team if I write a code it works beautifully but it's not clean it it cannot get merged at all I'll have to spend like 10 more days to clean it whatever it takes it takes but I need to make it clean so that code review is like one maybe you would in your team it was not practiced well enough so try to have good engineering practices some of the things they will take care it's not just your responsibility the the setup nowadays with the latest tools and technologies they enforce you to have a clean code so the first barrier would be the code review I would say yeah then a senior dev or an expert would never allow the messy code to get merged into the production so that's what we follow in our team and that's the first line of blockage for messy code yeah I hope that answers okay any any more questions I don't know where Lin went I am a front end and back end developer I I usually I I have very minimal knowledge on that part I will skip this question or maybe in the audience somebody have a better answer because I really don't have that expertise to answer like how do we like maintain cleanliness in the cloud architecture I am sorry I really can't think of any answer for that any anyone cloud experience can share more on his okay you want to share I'm really sorry I don't have expertise in that area I haven't really touched that part in my career till now okay I think that's all since I was not able to answer I'm not going to take any more questions let's move to