avatarBirat Rai

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

1816

Abstract

class="hljs-number">2</span>);</pre></div><p id="3ff5">What can you reason for all of these constants? Can you guess what they represent.</p><p id="d522">Now, consider the following</p><div id="dfb1"><pre><span class="hljs-attribute">float</span> gravitationalForce = <span class="hljs-number">9</span>.<span class="hljs-number">81</span>; <span class="hljs-attribute">float</span> timeInSec = <span class="hljs-number">5</span>; <span class="hljs-attribute">float</span> displacement = (<span class="hljs-number">1</span>/<span class="hljs-number">2</span>) * gravitationalForce * (timeInSec ^ <span class="hljs-number">2</span>)</pre></div><p id="2540">Do I even have to ask what those constants mean? That’s the power of self-documented code.</p><p id="1b93" type="7">Code that allegedly explains itself without the need of extraneous documentation, like flowcharts, UML diagrams, process-flow state-diagrams, etc is Self-Documenting Code.</p><blockquote id="6887"><p><b>If it’s Self-Documenting Code, we need no comments?</b></p></blockquote><p id="80b7">Consider the scenario again.</p><div id="ded4"><pre><span class="hljs-built_in">float</span> a = <span class="hljs-number">9.81</span>; <span class="hljs-comment">//gravitational force</span> <span class="hljs-built_in">float</span> b = <span class="hljs-number">5</span>; <span class="hljs-comment">//time in seconds</span> <span class="hljs-built_in">float</span> c = (<span class="hljs-number">1</span>/<span class="hljs-number">2</span>)a(b^<span class="hljs-number">2</span>) <span class="hljs-comment">//multiply the time and gravity together to get displacement.</span></pre></div><p id="7a12">Would you be satisfied with this code, or the one which was self-documenting.</p><p id="63e0">This should be one good reason enough for you to not add co

Options

mments but rather have a self-documenting code.</p><blockquote id="b907"><p><b>When you should comment?</b></p></blockquote><p id="07c1">Comments aren’t necessarily evil.</p><p id="1dcf">Why we should comment is discussed in the following <a href="https://readmedium.com/step-17-comment-only-what-the-code-cannot-say-kevin-henney-8d06337f168a"><b><i>Seventeenth Step</i></b></a>.</p><p id="028f" type="7">TL;DR Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.</p><p id="8dd2" type="7">~ Steve McConnell</p><p id="5a8e"><a href="https://readmedium.com/97-journey-every-programmer-should-accomplish-a0c53dbbfd47"><i>Go to the series</i></a>.</p><p id="a92f">Go to <a href="https://readmedium.com/step-15-code-with-reason-yechiel-kimchi-d673c15e7908"><b><i>Fifteenth Step</i></b></a>.</p><p id="4eda">Go to the <a href="https://readmedium.com/step-17-comment-only-what-the-code-cannot-say-kevin-henney-8d06337f168a"><b><i>Seventeenth Step</i></b></a>.</p><blockquote id="ba78"><p><b>References:</b></p></blockquote><ul><li><a href="https://www.gitbook.com/book/97-things-every-x-should-know/97-things-every-programmer-should-know/details"><i>97 things Every Programmer Should Know</i></a> ~ Git Book</li><li><a href="https://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484"><i>97 Things Every Programmer Should Know</i></a> ~ Paperback</li><li><a href="http://wiki.c2.com/?SelfDocumentingCode"><i>Self-Documenting Code</i></a><i> ~ Wiki.c2</i></li><li><a href="https://medium.freecodecamp.org/code-comments-the-good-the-bad-and-the-ugly-be9cc65fbf83"><i>The good-bad and the ugly of comments</i></a> ~ Medium</li></ul></article></body>

Step 16: A Comment on Comments ~ Cal Evans

This is the Sixteenth Step towards gaining the Programming Enlightenment series. If you didn’t learn the Fifteenth Step, read it.

“Real programmers don’t comment their code. If it was Hard to Write, it should be Hard to Understand”

~ Tom Van Vleck

Good Code is self-documenting”. How many times we hear this or repeat this as a daily mantra. It’s a cliché.

So, should we never comment our code? Yes/No (Why explained later.)

But, should it be self-documenting? Yes

What is a Self-Documenting Code ?

Remember Step 11, if not go ahead, refresh it.

float a = 9.81; 
float b = 5; 
float c = .5 * a * (b^2);

What can you reason for all of these constants? Can you guess what they represent.

Now, consider the following

float gravitationalForce = 9.81;
float timeInSec = 5;
float displacement = (1/2) * gravitationalForce * (timeInSec ^ 2)

Do I even have to ask what those constants mean? That’s the power of self-documented code.

Code that allegedly explains itself without the need of extraneous documentation, like flowcharts, UML diagrams, process-flow state-diagrams, etc is Self-Documenting Code.

If it’s Self-Documenting Code, we need no comments?

Consider the scenario again.

float a = 9.81; //gravitational force
float b = 5; //time in seconds
float c = (1/2)*a*(b^2) //multiply the time and gravity together to get displacement.

Would you be satisfied with this code, or the one which was self-documenting.

This should be one good reason enough for you to not add comments but rather have a self-documenting code.

When you should comment?

Comments aren’t necessarily evil.

Why we should comment is discussed in the following Seventeenth Step.

TL;DR Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.

~ Steve McConnell

Go to the series.

Go to Fifteenth Step.

Go to the Seventeenth Step.

References:

Programming
Java
Android
Software Development
Coding
Recommended from ReadMedium