Microsoft has done it again!
I've been dabbling with C# 6.0 features and I am really liking it. However, Microsoft has made adoption a real problem.
C# 6.0 is only supported in Visual Studio 2015. Ok so far but Visual Studio 2015 will only install on Windows 8 or later.
Gack!
Windows 8 was stillborn and no one wants to install it. Microsoft tried to convert its Windows desktop OS to a tablet OS and made a spectacular mess of it. So much so that they hastily released a Windows 9 (which they called 8.1 so they could offer it as a free upgrade). So dramatically didn't it fix things that they have now also offered Windows 10 as a free upgrade. People still don't want it so they have now taken the rather extreme measure of dramatically shortening the support agreement for Windows 7.
However, the whole mess of convolving the tablet OS with the desktop OS has left everyone afraid. Microsoft is trying to make the upgrade even easier (update is becoming more like a service pack) but many people that have Windows 7 aren't taking the bait.
In my office we are mostly still on Windows 7 and people are not eager to install new Windows versions. A few nice syntactic features in C# 6.0 aren't going to push people over the hump.
So, I've had to abandon C# 6.0 for now. I imagine this experience will be common and that adoption of C# 6.0 will be weaker than it should be.
To fix this Microsoft could decouple VS 2015 from Windows 8 or back port C# 6.0 into VS 2012. Otherwise, they risk losing momentum with what is really a great language and development environment. Come on guys, give us some better options.
Wednesday, 2 December 2015
Use Commit Discipline to Limit Code Entropy
Source control software is a basic tool that we are all familiar with but it is often perceived most importantly as a management tool to associate work with bug/feature tickets and manage deployment to release branches.
It is also a very useful for keeping code clean which can be especially important if you have mission critical code areas.
It is very simple and not particularly time consuming: look at all the differences when committing code and make sure your commit is clean. If your code base is clean you want to keep it that way and to aid troubleshooting of new bugs you want to be able to trace the change history.
One common scenario is that a change has required experimentation and debug logic. Once you finalize an approach you may have remnants of experiments, debugging logic and fragmented logic. Review this code from the perspective of the finalized approach. Ensure it is clean. It is surprising how often I've avoided committing vestiges of the development process.
Keep the granularity of commits as small as possible. It is a great way to focus on the change in context. For example, as part of a new application feature you've added a new method to your Rectangle class. Reviewing and committing the Rectangle change separately creates a focus on the Rectangle class that will help to maintain the intent and overall design of the Rectangle class.
Avoid coupling refactoring and gratuitous changes that obscure differences with functional changes. Implement refactoring and cosmetic changes as a separate commit and note in the commit comment that there are no functional changes. A simple example is moving code around. As a class grows it can help to reorganize the code layout but most source control software sees these moves as differences. If there is an actual difference in the function you have moved it is likely you won't notice it.
It's also a good time to review the area around your change. Are there code comments that are affected by your change? Have you obviated or orphaned existing code or variables?
Keeping mission critical commits clean is a very simple way to keep your mission critical code and its history clean. The second law of thermodynamics applies to all systems, including a software system. All changes will tend to increase entropy (disorder) but we can minimize the disorder by the these simple practices.
You don't have to be as disciplined everywhere but I find that developing this simple discipline where it is most important becomes habit forming and helps improve the quality of all commits.
It is also a very useful for keeping code clean which can be especially important if you have mission critical code areas.
It is very simple and not particularly time consuming: look at all the differences when committing code and make sure your commit is clean. If your code base is clean you want to keep it that way and to aid troubleshooting of new bugs you want to be able to trace the change history.
One common scenario is that a change has required experimentation and debug logic. Once you finalize an approach you may have remnants of experiments, debugging logic and fragmented logic. Review this code from the perspective of the finalized approach. Ensure it is clean. It is surprising how often I've avoided committing vestiges of the development process.
Keep the granularity of commits as small as possible. It is a great way to focus on the change in context. For example, as part of a new application feature you've added a new method to your Rectangle class. Reviewing and committing the Rectangle change separately creates a focus on the Rectangle class that will help to maintain the intent and overall design of the Rectangle class.
Avoid coupling refactoring and gratuitous changes that obscure differences with functional changes. Implement refactoring and cosmetic changes as a separate commit and note in the commit comment that there are no functional changes. A simple example is moving code around. As a class grows it can help to reorganize the code layout but most source control software sees these moves as differences. If there is an actual difference in the function you have moved it is likely you won't notice it.
It's also a good time to review the area around your change. Are there code comments that are affected by your change? Have you obviated or orphaned existing code or variables?
Keeping mission critical commits clean is a very simple way to keep your mission critical code and its history clean. The second law of thermodynamics applies to all systems, including a software system. All changes will tend to increase entropy (disorder) but we can minimize the disorder by the these simple practices.
You don't have to be as disciplined everywhere but I find that developing this simple discipline where it is most important becomes habit forming and helps improve the quality of all commits.
Subscribe to:
Posts (Atom)