<story><title>Coding Skill and the Decline of Stagnation</title><url>http://notch.tumblr.com/post/15782716917/coding-skill-and-the-decline-of-stagnation</url></story><parent_chain><item><author>jarrett</author><text>Controversial might be too strong a word, but there is a counterargument to be made.&lt;p&gt;Suppose you have a member named &quot;x.&quot; Someday, you might want to stop storing x, and instead make it a calculated value. At which point you&apos;ll need a method. Or, when setting x, you may someday want to increment a counter, or transform the input data, or take some other action. Again, you&apos;ll need a method.&lt;p&gt;Yes, it&apos;s very easy to add an accessor later. But then you&apos;ll most likely have to edit every line of code that accessed the now-defunct member variable. Your IDE may make this easy, but I&apos;d still prefer not to have to do it.&lt;p&gt;That&apos;s not to say writing accessors is &lt;i&gt;always&lt;/i&gt; the best choice. I&apos;m just saying there &lt;i&gt;can&lt;/i&gt; be good reasons to do it. Like all things in software engineering, there&apos;s no one-size-fits-all rule about this. Notch is right about the bloat accessors create, so you have to weight the advantages and disadvantages yourself in each case.</text></item><item><author>pigs</author><text>&quot;I still stubbornly believe the whole “private members accessed via accessors” thing in java is bullcrap for internal projects. It adds piles of useless boilerplate code for absolutely no gain when you can just right click a field and chose “add setter/getter” if you NEED an accessor in the future.&quot;&lt;p&gt;Is this a controversial stance? It seems like common sense, unless I&apos;m misunderstanding something.&lt;p&gt;EDIT: To clarify: I assume he&apos;s saying &quot;don&apos;t add accessors by default for all private members unless you need to, because you can always go back and add it if you really need it&quot;, which is common sense for any project, external or internal. I&apos;m pretty sure he&apos;s not saying &quot;don&apos;t add accessors, just use public members&quot;, which is controversial, IMO, even for internal projects.</text></item></parent_chain><comment><author>jiggy2011</author><text>I think this idea is that you can use &quot;properties&quot; rather than public class variables.&lt;p&gt;Then you can convert your public vars into properties at a later date.&lt;p&gt;This means that you will not have to (necessarily) rewrite your code as the language knows that&lt;p&gt;a =  myobj.myvar&lt;p&gt;now should call getmyvar() in the containing class and:&lt;p&gt;myob.myvar  = a&lt;p&gt;should call setmyvar(a) , I know that C# certainly allows this.</text></comment>
<story><title>Coding Skill and the Decline of Stagnation</title><url>http://notch.tumblr.com/post/15782716917/coding-skill-and-the-decline-of-stagnation</url></story><parent_chain><item><author>jarrett</author><text>Controversial might be too strong a word, but there is a counterargument to be made.&lt;p&gt;Suppose you have a member named &quot;x.&quot; Someday, you might want to stop storing x, and instead make it a calculated value. At which point you&apos;ll need a method. Or, when setting x, you may someday want to increment a counter, or transform the input data, or take some other action. Again, you&apos;ll need a method.&lt;p&gt;Yes, it&apos;s very easy to add an accessor later. But then you&apos;ll most likely have to edit every line of code that accessed the now-defunct member variable. Your IDE may make this easy, but I&apos;d still prefer not to have to do it.&lt;p&gt;That&apos;s not to say writing accessors is &lt;i&gt;always&lt;/i&gt; the best choice. I&apos;m just saying there &lt;i&gt;can&lt;/i&gt; be good reasons to do it. Like all things in software engineering, there&apos;s no one-size-fits-all rule about this. Notch is right about the bloat accessors create, so you have to weight the advantages and disadvantages yourself in each case.</text></item><item><author>pigs</author><text>&quot;I still stubbornly believe the whole “private members accessed via accessors” thing in java is bullcrap for internal projects. It adds piles of useless boilerplate code for absolutely no gain when you can just right click a field and chose “add setter/getter” if you NEED an accessor in the future.&quot;&lt;p&gt;Is this a controversial stance? It seems like common sense, unless I&apos;m misunderstanding something.&lt;p&gt;EDIT: To clarify: I assume he&apos;s saying &quot;don&apos;t add accessors by default for all private members unless you need to, because you can always go back and add it if you really need it&quot;, which is common sense for any project, external or internal. I&apos;m pretty sure he&apos;s not saying &quot;don&apos;t add accessors, just use public members&quot;, which is controversial, IMO, even for internal projects.</text></item></parent_chain><comment><author>cstuder</author><text>No.&lt;p&gt;C# and Objective-C (And I assume similar languages too) can have public accessors which are not used like function. No need to add ()&apos;s everywhere.</text></comment>