<story><title>Writing code with multiple overlapping side effects with a straight face</title><url>https://blogs.msdn.microsoft.com/oldnewthing/20170719-00/?p=96645</url></story><parent_chain><item><author>userbinator</author><text>I wonder if the first one was meant to be&lt;p&gt;&lt;pre&gt;&lt;code&gt;    a -= a * a;
&lt;/code&gt;&lt;/pre&gt;
which evolved from&lt;p&gt;&lt;pre&gt;&lt;code&gt;    a *= a;
&lt;/code&gt;&lt;/pre&gt;
after the author thought &amp;quot;I need to subtract its square from itself, not just square it&amp;quot;. I can see how this could occur in numerical code.&lt;p&gt;I&amp;#x27;ve noticed there are two opposing schools of thought on issues of &amp;quot;insane code&amp;quot; like this; on one side there&amp;#x27;s &amp;quot;use the language to the fullest if it makes sense to&amp;quot;, and on the other is &amp;quot;avoid anything that might be the slightest bit confusing&amp;quot;. I think that taking either of those to their logical conclusion is not a good idea --- in the former case, you&amp;#x27;ll end up with extremely dense and (initially) difficult-to-understand code, but the latter case will cause a gradual degradation of code into something approaching the verbosity of Asm, but with none of the benefits (e.g. &amp;quot;ternary operators are confusing, don&amp;#x27;t use them; multiple levels of precedence are confusing, so always fully parenthesise expressions; nested parentheses are hard to read, so don&amp;#x27;t use them either and only do one operation per statement; boolean expressions are confusing, so always use if&amp;#x2F;else; nested if&amp;#x2F;else are confusing, so don&amp;#x27;t nest and always refactor to use a function call, etc. etc.)&lt;p&gt;It does seem that different languages vary in where they are on this scale, with more &amp;quot;exotic&amp;quot; ones like APL tending highly towards the former (interesting related discussion: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=13565743&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=13565743&lt;/a&gt; ) and C#&amp;#x2F;Java towards the latter. The ideal is probably somewhere in the middle.</text></item></parent_chain><comment><author>metaobject</author><text>&amp;quot;I&amp;#x27;ve noticed there are two opposing schools of thought on issues of &amp;quot;insane code&amp;quot; like this; on one side there&amp;#x27;s &amp;quot;use the language to the fullest if it makes sense to&amp;quot;, and on the other is &amp;quot;avoid anything that might be the slightest bit confusing&amp;quot;.&lt;p&gt;This is a false dichotomy.  How about &amp;quot;use the language to it&amp;#x27;s fullest, within reason (avoiding things like multiple side effects per source line), but when non-obvious code is written, document it.&amp;quot;&lt;p&gt;At least, I&amp;#x27;d say that describes my approach.</text></comment>
<story><title>Writing code with multiple overlapping side effects with a straight face</title><url>https://blogs.msdn.microsoft.com/oldnewthing/20170719-00/?p=96645</url></story><parent_chain><item><author>userbinator</author><text>I wonder if the first one was meant to be&lt;p&gt;&lt;pre&gt;&lt;code&gt;    a -= a * a;
&lt;/code&gt;&lt;/pre&gt;
which evolved from&lt;p&gt;&lt;pre&gt;&lt;code&gt;    a *= a;
&lt;/code&gt;&lt;/pre&gt;
after the author thought &amp;quot;I need to subtract its square from itself, not just square it&amp;quot;. I can see how this could occur in numerical code.&lt;p&gt;I&amp;#x27;ve noticed there are two opposing schools of thought on issues of &amp;quot;insane code&amp;quot; like this; on one side there&amp;#x27;s &amp;quot;use the language to the fullest if it makes sense to&amp;quot;, and on the other is &amp;quot;avoid anything that might be the slightest bit confusing&amp;quot;. I think that taking either of those to their logical conclusion is not a good idea --- in the former case, you&amp;#x27;ll end up with extremely dense and (initially) difficult-to-understand code, but the latter case will cause a gradual degradation of code into something approaching the verbosity of Asm, but with none of the benefits (e.g. &amp;quot;ternary operators are confusing, don&amp;#x27;t use them; multiple levels of precedence are confusing, so always fully parenthesise expressions; nested parentheses are hard to read, so don&amp;#x27;t use them either and only do one operation per statement; boolean expressions are confusing, so always use if&amp;#x2F;else; nested if&amp;#x2F;else are confusing, so don&amp;#x27;t nest and always refactor to use a function call, etc. etc.)&lt;p&gt;It does seem that different languages vary in where they are on this scale, with more &amp;quot;exotic&amp;quot; ones like APL tending highly towards the former (interesting related discussion: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=13565743&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=13565743&lt;/a&gt; ) and C#&amp;#x2F;Java towards the latter. The ideal is probably somewhere in the middle.</text></item></parent_chain><comment><author>chii</author><text>&amp;gt;  a gradual degradation of code into something approaching the verbosity of Asm&lt;p&gt;there&amp;#x27;s a simple rule of thumb - if you can&amp;#x27;t immediately and unabmiguously deskcheck the expression as it is written, it&amp;#x27;s too complicated and should be simplified.</text></comment>