You. Hello everyone. Thank you so much for joining this session. My name is Karan and today I'll be talking about the topic why clean code is no longer a myth. So before I begin with the presentation, I would like to thank the entire team of Con 42 for giving me this opportunity to present my talk. So thank you so much. Here's a brief introduction. About me so I have been working primarily as an Android mobile developer for the past five plus years now. I have been working mainly on technologies like AI, AR and VR. More recently I've been involved in developing web applications using react and angular, and my current work assignment includes developing mobile applications using React native. And apart from being passionate about technology, I also love writing poems, traveling to different places across the globe, and meeting new people. So that's about me in a nutshell. Now, needless to say, most of us are working in software projects which are agile in nature, and they are characterized by the fact that they are result oriented, involves continuous improvement, and no longer are we working in silos. We are all working in either small or medium sized cross functional teams. The second block actually talks about software design principles. So I've listed four of these software design principles, and these software design principles also have been there for quite some time now. However, it is the lack of the early adoption of these principles in software projects that has actually caused a lot of concerns. Now, more often than not, software projects tend to incorporate these principles either towards the frag end of the project, when it's going to be launched, or sometimes even after it has launched. So here it is important to know that these kind of software design principles have to be incorporated as early as possible in the software development lifecycle. So here I would like to specifically mention about one of the principles, which is separation of concerns. Now, separation of concerns basically means that you divide a program into say exists sections and then each section basically handles a separate concern. So these kind of software design principles are especially important nowadays in software projects. Coming to the third block, which talks about the age in which we all live in, which is the age of automation. Now, the age of automation, basically one of the benefits of the age of automation is that you get to use more tools and accelerators, and one of the main advantages is that it helps to reduce the overall cost and the effort. So the age of automation certainly is something that we are all a part of, and we are all using it in our day to day lives as well. So before coming to the main topic of the presentation, here is a short disclaimer. So this session is not about why to write clean code, or neither does it talk about what is clean code or what is clean architecture, nor does it try to answer the question about why don't so software engineers write clean code. So the objective of this session mainly is to describe how one can actually go about developing or writing a clean code. And it's talking about one of the tasks that software developers even today feel that it is something far fetched. And if you happen to be one of those developers, then perhaps you might have guessed it by now. It is writing clean code. So that is basically the objective of the session. So years are trimmed down, a version of a day in the life of a software developer. So software developer is someone who checks in his code at say regular intervals and submits finally a pull request, which is then internally reviewed by a team of developers, so colleagues or senior members in the team. And basically the developers would then provide some feedback based on which the person who developed the code would refactor it, and then finally this would go on until the PR has been approved. Now once the PR has been approved, this would basically trigger some scripts, so it can be some build scripts which would in turn execute a pipeline. And here is where the DevOps team would come into picture, where they would be involved mainly in the monitoring of the pipeline, determining whether the operations of the pipeline are going on smoothly. And the output of this process would be say a binary or an artifact that would be produced, which would then be deployed to a QA environment. And here is where the testing team would come into play, where they would actually be involved more in the testing of the app or the solution, and against a set of test cases, of course. And then they would also be providing their feedback on a continuous basis to the development team. So now, assuming basically all this has happened and the issues have been resolved and there are no potential bottlenecks, then the testing team would ideally give a green signal and the application would go into production or something that we call as going live. So this is a feeling that I think most of us have experienced by now. And when this kind of a situation or moment comes in, we feel something like this. It's this kind of a moment where you feel that your code actually has worked and you have actually produced a working version, which is fine and it has gone into production. But if you're one of those who loves writing clean code, then perhaps this is really not the icing on the cake. So there are some drawbacks which are basically associated with this kind of an approach. So in this case, the developers, they are mainly focused on making the solution, I would say work. So I would say there's less amount of time which is actually spent on the refactoring of the code. So there are no, or I would say limited precommit checks which are in place. And there is always an ongoing debate of whether the developer should actually invest his time in writing a working code, or whether he should invest his time in writing a maintainable code. So there is always a debate that goes on about this. So these kind of problems do exist, but then there are some ways by which you could tackle them. So for now, let's try to deviate from the world of technology and move to the world of human psychology. Now, in case of human psychology, there is something that we all have known about which is nothing but a habit. So habit is something that is not developed overnight. So writing clean code also needs to be, or become a habit. So what are the four stages, you may ask, of building a habit? So I have listed them down, so they are nothing but queue craving, response and reward. So q is nothing but something that triggers your brain to initiate a particular behavior and action, and also basically helps you to predict or provide some more information of the actual reward. Craving, on the other hand, is the motivational force behind developing the habit. The response basically in this case represents the actual habit itself. And the reward, as the name suggests, basically is the results or the outcomes of developing this kind of a habit. So these are the four stages, I would say, of building a habit. But if we had to map this in terms of our main objective of writing clean code, so this is what we would eventually come up with. So in the case of writing clean code, our queue basically would involve removing of debt code, finding of unused variables, automating the formatting of the code, and applying certain custom rules. On the other hand, our craving basically, or the motivation behind developing this habit would be to write maintainable code to maximize the refactoring of the code, and eventually to minimize the amount of bugs. The response in this case would involve using githubs and linting, which I'll be talking about in the subsequent slides as well. And although the rewards of developing this kind of habit would be many, but I have listed down three of the important ones, which is basically consistency in terms of the code, effort and cost savings in terms of the development time, and also achieving a higher code quality. So these are the three important rewards of developing this kind of a habit. So the question now is that how does actually one go about developers this habit. So one of the steps that I found useful in this is something that I usually recommend, which is basically using something called as husky. So husky, for those of you who are not aware, is nothing but a popular Javascript or NPM package which is already out there, a framework which allows developers to run certain scripts while doing certain specific actions. Now these actions can be either in the form of githubs, which are internally also scripts which run every time a particular event occurs in your git repository. And these events also can be of different, different types. So it can be a pre commit, a pre push. So these are the various events, and the gith basically would be executed each time, every time a particular event occurs. So in that case, how does actually one go about installing husky or setting Husky up? The answer is pretty straightforward. You could just use a simple command. So in this case, the command is NPX husky in it. So, which basically would inject a kind of a prepare script in your package or JSON file, and the installation would move on. Pretty straightforward. So this is basically a simple way by which you could install husky. So here I would like to also mention that it is recommended to use, of course, the latest version of Husky, because if you're one of those who have used Husky before, and if you're now migrating from say a low version, say version four, to the latest version around this time, which is six. So you have to note that there have been a lot of significant changes in the way husky now actually interacts with the whole JS ecosystem. So it has been actually kept away. So I would say decoupled in a way and making it more easier to use. So that is basically one of the advantages with the newest version. So I would recommend people trying husky for the first time to use the new version and set it up. So this is about the setup, which is basically pretty straightforward. So let's now understand, how does one write his first pre commit hook. So a precommit hook can be also written in the form of a script. So in this case, basically I have included a pre commit hook as a part of my script. And in this case, this is a pretty simple example where I have actually used a precommit hook, which does an Eslint kind of task. So it does an Eslint minus minus fix, which is basically going to find out or solve the most common errors or commonly occurring errors for me. So it can be in terms of white spacing, or it can be in terms of variable declaration. So this would basically help me to ensure that developers, before developers check in their code, most of the commonly occurring problems have been fixed and the developers can then check in their code. So this kind of a pre commit hook would, although it's a pretty simple one, but it would help you to ensure that whatever code has been checked in, it's of good quality. So this is basically a very simple example of a precommit hook. So coming to the next slide, so I mentioned about Eslint, one of the slides prior to this, and I mentioned that Eslint is also one of the popular frameworks which are there, and Eslint actually helps developers to find problems in their code without actually running or executing it. And prettier on the other hand, is like an optional code formatter. So there are many code formatters out there, but prettier is something that one uses quite often, especially in terms of JavaScript and react based applications, I would say. And if you are one of those who uses react JS or is developing react JS based applications, then the good part is that the create react app already comes bundled in with the Eslint config. So as you might be aware, the eslint has a lot of plugins that it has, and you can actually include them as a part of your configuration. Or in that case, if you are using react JS, there would be already a, by default a set of plugins which would be there, but you can always go ahead and install any other plugin if required. So that is one of the things that you could do in case of Eslint. And prettier on the other hand, would be something that also you could use if you are well acquainted with it, and if you'd like to make code formatting a lot easier. So that is basically done using a simple command which I have listed down, which is basically doing a yarn add and to include prettier in your application. So this is basically a pretty simple way of installing Eslint and prettier and coming to the next slide. Now, Eslint, as I mentioned, would help you to find out problems in a code without executing it, and that is because of certain rules. So there are certain rules that you could add for basic syntax validation or variable declaration or say brace styles to fit your requirements of the project. And there are two ways actually of configuring Eslint. So one way is basically you create an eslint RC Js file at the root level of your project. Or you could ideally go with the second approach, which is to add Eslint config feed in the package JSon. So this is another approach where you can specify your rules and your configuration. So I have actually gone with the first approach. In this case, I have created an Eslint RC Js file in which I have included all the rules which are going to be applicable for my project. So the good part is that here you could actually do a lot of customization in terms of your rules and try to make it more stricter or depending upon your project requirements. So Eslint offers you that flexibility and one can actually take into account all the commonly occurring problems or commonly occurring issues that developers face and also try to set up some rules so that it could be avoided before committing the code. So these kind of rules also can be added as a part of the Eslint RC js file. So this is a simple example of how one can configure rules using Eslint and coming to the next slide. So in addition to linting of code, I feel that one of the most important tasks which is often neglected is providing meaningful commit messages. So in addition to linting of code, I would say commit linting is also especially important when it comes to writing or writing clean code, and even in that case tracking down of commit messages, especially in software projects which have been going on for like say several years. So it's very important also to make sure that every developer basically follows a particular standard in terms of commit messages. And for this, basically one can actually leverage the commit lint. So the commit lint also can be, it's also nothing but similar to the ES lint. But in this case you could have different set of rules. So of course this will be more related to related in terms of the way you name or provide your commit messages. So in this case also you could use a simple yarn command which I have listed down to include those packages as a part of your project and you could get started using it. So this is also pretty straightforward where using this kind of a linting type, actually you could ensure that every developer follows a particular standard in terms of his commit messages, which eventually, later on maybe in the project, can be tracked by someone in case of an issue. So that is also something that I would recommend using as well. So coming to the next slide, which talks about environmental configurations, now this is again a very important aspect of writing clean code, because as developers we often work on different operating systems, be it windows, Linux or macOS. So based on the different versions or different dependency versions, there's always some kind of a conflict that may arise. Now, usually in a dev environment, one does not typically run the NPM install command unless he or she is running the project for the first time or there are some version changes that needs to be done. So in this case, the good part is that we have something called as a node version manager. So this basically it is used to install a specific version, or you can say multiple versions of a particular framework or library, and one can do that using say the command like NVM install where you specify the version you want to use, and then using the NVM use command, you start using that in your particular project. So then irrespective of the version that runs on your operating system, this version would then be specific to that project, and it will help you to ensure that you have a consistency in terms of the versioning with other developers who might be using maybe a different operating system or a different version on their system. So this would help you ensure that there's a consistency among the versions and could help you to basically even avoid any dependency conflicts, aversion conflicts in the future. So this is one of the, I would say one of the main advantages of using this kind of an environmental configuration as well. So moving on. I would say writing clean code definitely would help you to improve the efficiency and the overall output of your code and the code quality itself. And I feel that project team should basically focus more on the environmental setup and configuring the frameworks for clean code before even the actual development starts. And in my opinion, refactoring should definitely be made a continuous process where developers should focus more on refactoring the code rather than actually producing, say, just a working version of the code. So that's it from my side. And before I conclude, I would like to share a very interesting quote that I came across on the Internet, which says that every developers loves to write clean code, yet not every developer writes code in the same way. So that's about it from my side. So here are a few references based on which I compiled my presentation today, and thank you once again to the entire team of Con 42 and hope all of you enjoyed the session. Please feel free to get in touch in case of any questions or any queries. So thank you so much once again.