<story><title>What I have changed my mind about in software development</title><url>https://henrikwarne.com/2023/09/10/what-i-have-changed-my-mind-about-in-software-development/</url></story><parent_chain></parent_chain><comment><author>JohnBooty</author><text>&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Over the years I have realized that some comments are 
    needed and useful. These days I add comments when there 
    is something particularly tricky, either with the 
    implementation, or in the domain.
&lt;/code&gt;&lt;/pre&gt;
Ah, yes. Another convert. There are dozens of us. Dozens!!&lt;p&gt;Nothing makes me feel crazier than trying to get fellow engineers to comment their code. Code alone can only tell you the &amp;quot;what.&amp;quot; If the &amp;quot;why&amp;quot; is not obvious, comment it.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Unit testing private methods. 
&lt;/code&gt;&lt;/pre&gt;
I am always dismayed by engineers who vote a hard and unyielding &amp;quot;no&amp;quot; on this issue.&lt;p&gt;I guess ideally your private methods should not be tested directly. If you work at an ideal shop doing ideal things under ideal conditions, please let me know if you are hiring.&lt;p&gt;In all or most of these cases the tests for private code will hopefully be somewhat temporary; perhaps think of them as scaffolding used during construction or renovation.&lt;p&gt;- For example, perhaps you have a good reason to write the private methods first and you would like to make sure they are sound before proceeding.&lt;p&gt;- Perhaps you have a division of labor due to a time crunch and you are writing the private methods while somebody simultaneously writes the public methods.&lt;p&gt;- Perhaps you are encountering some thorny preexisting code with no test coverage and you would like to just make sure things work.&lt;p&gt;- Perhaps the public methods are undergoing a lot of flux and you would like to make sure the private methods do not suffer regressions during this flux&lt;p&gt;- Sometimes it&amp;#x27;s just &lt;i&gt;easier&lt;/i&gt; to test private methods directly rather than indirectly via a public interface. Maybe this is a code smell, but also maybe you don&amp;#x27;t have time for a full refactor.</text></comment>
<story><title>What I have changed my mind about in software development</title><url>https://henrikwarne.com/2023/09/10/what-i-have-changed-my-mind-about-in-software-development/</url></story><parent_chain></parent_chain><comment><author>andrewstuart</author><text>&amp;gt;&amp;gt; I used to think that the names of the classes, methods and variables should be enough to understand what the program does. No comments should be needed. Over the years I have realized that some comments are needed and useful.&lt;p&gt;Comments are needed where there is more to the code than just reading it.  Where there is some external reason WHY.  Where it is written in a specific way for non-obvious reasons.  Where there are pitfalls and dangers in changing the code. Where this specific approach is the result of fixing some problem and if you change it then you might be reintroducing a problem.&lt;p&gt;There&amp;#x27;s lots of reasons to comment your code, but mostly I think code should be the documentation.&lt;p&gt;The fewer comments the better, because then developers who come later will see comments and thing &amp;quot;this must be important because there is a comment here&amp;quot;.  Too many comments dilutes the value of comments.&lt;p&gt;When it really matters I start my comment with a couple of lines like this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;#x2F;&amp;#x2F; LISTEN UP!!!
  &amp;#x2F;&amp;#x2F; LISTEN UP!!!

&lt;/code&gt;&lt;/pre&gt;
I have to say, it seems strange that the author EVER thought that no comments should ever be needed - that seems like a strange and dogmatic conclusion to have come to.</text></comment>