Changing variables to val when possible?

kotlin · · 163 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>When I first started coding in Java I was taught that primitive data fields should use the keyword final when possible for the sake of immutability.</p> <p>I was wondering if you guys also do that with Kotlin. I&#39;ve read that making things immutable is more efficient and also helps readability. In essence, is it encouraged to change var to val if the attribute is never changed?</p> <hr/>**评论:**<br/><br/>yole: <pre><p>Yes, it is encouraged. There is an inspection in IntelliJ IDEA that tells you to do that, and can perform the replacement automatically.</p></pre>nutrecht: <pre><p>One of the biggest benefit of immutability is if you&#39;re in any multithreaded environment. Multiple threads poking around in the same piece of state is a recipe for disaster (concurrency issues are typical &#39;<a href="">heisenbugs</a>&#39;; often impossible to reproduce). You can often easily avoid this by simply not letting threads change objects by making them immutable. This is the primary reason why so many classes in java (Integer, String, BigInteger) are immutable. </p></pre>WikiTextBot: <pre><p><strong>Heisenbug</strong></p> <p>In computer programming jargon, a heisenbug is a software bug that seems to disappear or alter its behavior when one attempts to study it. The term is a pun on the name of Werner Heisenberg, the physicist who first asserted the observer effect of quantum mechanics, which states that the act of observing a system inevitably alters its state. In electronics the traditional term is probe effect, where attaching a test probe to a device changes its behavior.</p> <p>Similar terms, such as bohrbug, mandelbug, hindenbug, and schrödinbug (see the section on related terms) have been occasionally proposed for other kinds of unusual software bugs, sometimes in jest; however, unlike the term heisenbug, they are not widely known or used.</p> <hr/> <p><sup>[</sup> <a href="" rel="nofollow"><sup>PM</sup></a> <sup>|</sup> <a href=";message=Excludeme&amp;subject=Excludeme" rel="nofollow"><sup>Exclude</sup> <sup>me</sup></a> <sup>|</sup> <a href="" rel="nofollow"><sup>Exclude</sup> <sup>from</sup> <sup>subreddit</sup></a> <sup>|</sup> <a href="" rel="nofollow"><sup>FAQ</sup> <sup>/</sup> <sup>Information</sup></a> <sup>|</sup> <a href="" rel="nofollow"><sup>Source</sup></a> <sup>|</sup> <a href="" rel="nofollow"><sup>Donate</sup></a> <sup>]</sup> <sup>Downvote</sup> <sup>to</sup> <sup>remove</sup> <sup>|</sup> <sup>v0.28</sup></p></pre>luminous_arbour: <pre><p>Usually i&#39;ll use val by default and only change it to var if need be.</p></pre>SpoilerAlertsAhead: <pre><p>I feel dirty when I use var </p></pre>sombrastudios: <pre><p>Furthermore the Compiler can store the Variable in a different way, when it does not has to be mutated. I don&#39;t know too much about this, hope I don&#39;t talk Shit </p></pre>nutrecht: <pre><p>Close. It&#39;s not the javac compiler though (the compiler in the case of Java doesn&#39;t do much optimization at all), but the VM itself can optimise a lot more if it knows a value isn&#39;t going to change. </p></pre>jasie3k: <pre><p>It&#39;s the reference that&#39;s not going to change. State of the object can change, as it is not guaranteed that it will be immutable. </p></pre>nutrecht: <pre><p>Sure, but the goal is obviously not for just a single object to be immutable but for the entire tree to be. In these kinds of situations those trees tend to not be very deep. </p></pre>
163 次点击  
加入收藏 微博
0 回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet