Good Practices

Last week we did our first sprint review meeting, basically is a discussion about the tasks of the previous week, which tasks were finished and which tasks were not and why, and if their any problems facing any member of the team and how to deal with those problems, and also show the business owner the progress in the tasks and the finished features. For my tasks, I was not able to finish even half of them because all of the concepts were fairly new to me, but in the sprint planning meeting which held immediately after the review meeting my tasks from last sprint were simply transferred to this sprint and one more task was added to work on it also this sprint.
Last week I worked on fetching some data from the server using DTOs and network caller and display that info on a recycler view and create another POST request and its associated function to fetch more data from the server. The functionality of the network caller was already written I just reuse it in my view model, and yes I needed to create a view model to handle the calling and data fetching, and also I defined in the view model some LiveData objects and use an observers on my fragment to notify the required function whenever these data changes to acts upon that. I will talk about the view model and LiveData in another post, but in this post, I will focus on some points Islam discussed with me last week.
Islam regularly reviews my code that I regularly push to the project repository in GitLab. On the Thursday morning I found an email from Islam with some valuable and useful advices and good practices, and I would like to share a few of them with you:

1. 1. 1.  Islam told me that I have to commit only the source code not the output and generated files, because I was committing every file in the project and that made the remote repository in GitLab became very large, and according to Islam ideally it should be a few MBs. So I needed to delete all the build files and output files from only the remote Git repository to do that I found a good answer in StackOverflow, as follows:
         For a single file:
         git rm --cached mylogfile.log
         For a single directory:
         git rm --cached -r mydirectory
         And you typed that in the terminal of the Android Studio. After that, I needed to add a .gitignore file in my local repository and added files that I don’t need to commit, so Git will ignore these files whenever I do commit in my local repository.
      2. In my code, I have to abide by Kotlin formatting. In Android Studio you can simply do that by using the shortcut Ctl+Alt+L to reformat your code. I am using Linux Mint and this shortcut lock the screen by default, so I had to change that in the setting first before I was able to use that shortcut in Android Studio. check this answer in StackOverflow for more and the shortcut for other OS.
      3. In my code, I commented some parts of the code I didn’t need, but I want to keep them just in case, and my code looks kind of messy and not clean at all. So Islam told me just to delete those lines and whenever I need them I can always get them back from Git.
      4. Islam told me to avoid comments that describe what I am doing, instead, I have to extract the code and use the function name to describe what I am doing. He told me that descriptive comments are bad comments. Let me show you an example to demonstrate to you what he meant by that (the example in Kotlin):

   {
   .....
   var x = 1
   var y = 2
   var z = 3
   // Calculate the average of three integer numbers
   var average = (x + y + z) / 3
   ......
   }
   

   That comment is a descriptive comment and better way to do that is by separating the functionality of calculating the average in a separate function and let the name of that function to describe its functionality

   {
   .....
   var x = 1
   var y = 2
   var z = 3
   var average = calculateAverage(x, y, z)
   .......
   }
   fun calculateAverage(num1: Int, num2: Int, num3: Int) = (num1 + num2 + num3) / 3 
   

   That’s better and cleaner. Nothing better than a code that can describe itself.

   That’s it for this week.

   Till next week.