#NoMoreApologies

Introduction
Below are experiences of the coders at One World Coders in regards to #NoMoreApologies.

Julius
What are apologies in code?
Most of my days in programming, I try to explain my code with a follow-up comment to make it easier for whoever will inherit the codebase. This is to improve the readability of the code. I continued explaining myself with comments until I had a live coding session with Doug Bradbury (Founder One World Coders) and he made me understand that having those lines of comment simply means I'm apologising for not giving my code proper naming.

Instances of apologies

# add frequent renter points
frequent_renter_points += 1

# add bonus for a two day new release rental
if element.movie.price_code == Movie::NEW_RELEASE && element.days_rented > 1
    frequent_renter_points += 1
end

Solution

frequent_renter_points += rental.points

From the solution, you will notice that proper naming convention and clean refactor is all we need to deliver a human-readable code.

Kenneth

I am not going to say comments are good or bad. I say, it depends on the team or project you’re on. I have worked with teams that value comments in code because it is easier for the new devs to know what a specific section of code is doing or even documenting another section for code for scenarios that might arise. On the other hand, commenting code could reduce its quality because devs will not think about proper variable names, the right code workflow and also not testing code thoroughly thinking that the comments will make up for all this. This is a disadvantage to the growth of the developer. Being a good developer doesn’t only mean writing code that works but also it should be easy to read.

So my take on commenting code is if the right variable names are used, proper code flow is maintained and TDD practised in this case more of unit tests, then comments will not be needed.

Emmanuel

Before I joined One World Coders, I preferred to have comments and or docstrings for every method class and implementation of my code, clearly explaining what the section of the code is doing, returning, used for, etc. This has some pros and cons. The biggest advantage to me was that it made code easier to read as you didn’t have to dive into a function to know what it is doing, but rather read the comments and docstrings around it. The biggest disadvantage was that it made files almost double in length as the docstrings were sometimes even longer than the functions.

During one of the phases of the recruitment process at OWC, I submitted code with docstrings and comments and was told to modify my code by removing the docstrings and comments from the code so as to promote writing cleaner code. I immediately removed them of course, though I still didn’t clearly understand why. After going through the apprenticeship program at OWC, I came to realize that my code was a lot cleaner and easier to understand by teammates, even though I wasn’t having all the comments and docstrings to which I was formerly used.

#NoMoreApologies helped me write better and cleaner code (variable and function names, implementation, follow best practices, etc) 

Conclusion

According to Doug Bradbury, a comment in code is an apology for not being able to write easy to understand code and therefore you have to add comments to accompany the implementation for readers/teammates to understand what you are writing.

#NoMoreApologies is simply a term used to promote writing cleaner easy to understand code by having the code be self-explanatory.