There are times, however, when I’m doing temporary work at a client’s machine and I don’t want to use my personal SnagIt license, so I use the next best thing: Jing (also by TechSmith). It’s free, and it has several of the main features I use all the time in SnagIt.
Jing has a quick access feature that sits at the top of my screen:
I select the window or area I want to capture, perform some basic annotation, and then either put it on the clipboard (usually to paste it on Evernote) or upload it to screencast.com (free service from TechSmith) so I can easily share the image through a link with other people:
That’s it: simple free tool that I use a lot everyday and makes me more productive. Win-win.
I was asked this question this week: “When did you start writing clean code?”. I hadn’t thought of that before. Pondering on the question, I remembered when I started paying more attention to writing better code. It also made me think when I do not write clean code. Here’s what I came up with…
When did I start writing clean code?
Going back in time some 25 years, I was working with good old Clipper. Some of the files I was working with had thousands and thousands of lines of code. I had to print out pages of code on a dot-matrix printer and then draw lines to connect if-blocks and things like that in order to make some sense out of it.
Eventually, I figured out I could move some blocks of code out to separate functions, so instead of reading 5k lines of code, I’d need to read only 2k. As time went by, that codebase was way easier to understand.
When I do not write clean code
For me, it isn’t possible to write clean code all the time. For example:
- When I’m implementing some new feature and writing tests first
- In a case like this, once I have a failing test, I’ll write whatever code it takes to make the test pass. That could mean having one class with a lot of ugly code. I don’t care. Once my test is passing, then I’ll look back at the nasty code and will do my best to make it better, given what I currently have available (my skill with the programming language, my knowledge of the framework or libraries used, my understanding of the requirements, the time I have available, etc.);
- When I’m new to the programming language, framework, libraries, business domain, project…
- In cases like this, there’s really so much I can do. In the beginning, things will come out a little (or a lot) ugly. As I learn, things will get better.
I remember moving from FoxPro to C#. As much as I though I was a good FoxPro developer and wrote good code, I just know my C# code was terrible. It took a while to learn how to write better C#.
When I moved from C# to Ruby, things were slightly different: I already knew my Ruby code would look bad initially, so I first learned how to write tests! I didn’t even worry about writing clean tests; I only cared about writing some test so I could “write Ruby code with a C# accent”, and once the tests were passing, I’d get help from somebody who knew a lot of Ruby to show me “The Ruby Way” (or more specifically, the Rails Way) for doing certain things.
For me, at the end of the day I just want to make sure I wrote the best code I could, once again, given what I currently have available:
- My skillset in the programming language, framework, libraries, etc.;
- My understanding of the business domain;
- My time available
I mentioned how eager status code analysis is awful. A policy that forces developers to put XmlDoc comments is a good example of that.
This is how I see it: as I think through how I want to implement something I create an interface (created off tests I just wrote). The code might look something like this…
Right off the bat, VS is already showing me squigglies on the code I just wrote. I hover over it and this is what I see:
Right now I can’t even compile the code, and I don’t feel like typing Xml comments because I’m still thinking through my design and implementation. Parts of this interface are likely to be changed very quick, and any sort of documentation will become useless.
Since I need to conform with this policy, I use GhostDoc to just spit out the comments:
At this point I don’t really care whether the auto-generate comments make sense or not; I’m just satisfying what’s required in this development environment setup so I can get my immediate work done.
Of course, now what used to take just under 10 lines of code cannot even fit on my screen anymore and it requires scrolling!! That’s unacceptable to me. I can’t quite function seeing so much clutter! Fortunately, I’ve found this NoComment extension, which gets those comments out of my sight:
Now I can actually focus on what’s really important. Later, when I’m done with my design and implementation, then, and only then, I can review those Xml Comments prior to committing the work to the central source control repository.
I like static code analysis.
I like how it reminds me how I can improve the code by applying certain refactoring patterns.
I like how it tells me how I can clean the code by using a new language feature I might not be aware of.
I like how it enforces a certain style and conventions on a codebase changed by several developers.
However, I have grown a special distate for static code analysis that’s run way too eagerly!
What do I mean by that? I do not like it when it’s run as I type the code. Done that way, it prevents me from finishing my thoughts. Many times I’m trying out ways to implement something, and I don’t like static analysis bugging me about things that aren’t important at that point in time. Treating those as errors make things even worse as the IDE shows red squigglies and distracts me.
I don’t like static analysis even when I compile the code. Why not? Because it gets in my way as I go through the Red-Green-Refactor process.
Static code analysis should run when we push the code to the central repository. At that point, check-in policies could block the commit if there are violations to the rules. Such analysis run any time before that is a productivity killer.
A whole decade ago (yikes, I’m getting old…) I wrote about how I was Organizing Windows and Multiple Monitors. I still use that approach when I’m working on a PC with dual monitors. The only thing that has changed is how I get it to work in Visual Studio 2017.
So, let me explain the steps I take.
I first set all the windows in VS according to how I want them when I’m focused on coding. In that case, I want to make full use of all my real state, which means, use my screens wisely. My dual-monitor setup look somewhat like this:
Once I found my perfect setup, I then export my settings by going to Tools -> Import and Export Settings…:
I then unselect all settings and select only General Settings -> Windows Layouts:
I export the settings to a dual-monitor.vssettings file on a c:\tools\settings folder.
Next, when working using a single monitor (which is usually the case when I’m in a conference room and projecting my screen), this is what my single-monitor setup looks like:
Once I’ve found my perfect setup for single monitor work, I export the windows layout settings to a single-monitor.vssettings file to my c:\tools\settings folder.
Now, whenever I want to switch between the different layouts, all I need to do is to import the settings accordingly.
But if you’re switching between layouts too often every day, then automate the process of importing settings!
It seems like VS 2017 has dropped support for Macros (seriously?). Fortunately, there’s a nifty extension out there called Visual Commander (I mentioned I was using it for Toggling Visual Studio CodeLens On/Off, remember?).
Once you’ve installed Visual Commander, you are welcome to download the commands I created to import single/dual monitor VS settings and import it into your Visual Commander setup. Once you’ve imported it, you can easily switch between layouts by using the commands under the VCmd menu:
The VCmd commands are simple macros that automate that simple process.
Also, if being two clicks away (or Alt+C + a few key strokes to access the menu option and hit Enter), you can set a shortcut in VS to access those commands! (See this other post if you need to learn how to do that).
The company I work with is doing what it does best: Improving is improving!
We have recently finalized a partnership with ProSource Solutions, a management and information technology consulting firm headquartered in Ohio. This merger will continue growing the value we can bring to our clients, our services, and adds great expert Improvers. Those new Improvers significantly strengthen the breadth and depth of our technical consulting services, and training offerings.
Furthermore, it will expedite efforts for Improving to pursue its strategy to grow vertical technology specializations, through the delivery of Microsoft and cloud computing based solutions. ProSource is a preferred Microsoft Partner and has been awarded 5 consecutive “Top U.S. Partner of the Year” awards from Microsoft.
With similar company values and a focus on culture, we see significant alignment in business strategy and overall approach. It remains our top priority to establish and maintain trust not only with each other but with our clients, partners, communities, and others.
We welcome ProSource Solutions to the Improving brand and look forward to our future collective growth together!
To read more about this acquisition, please visit http://improving.com/thoughts/improving-acquires-prosource-solutions
In the last 40 days or so, I’ve published 20 posts (including this one). That’s my biggest number of posts ever! A personal goal I’ve had in the last two or three years has been to make this blog more active, and that’s what I’m doing.
The high number of posts has been motivated by my realization that I’m often asked about my opinion on a number of things, so I might as well share my opinions through this channel, as it may be of interest to a wider audience. Also, I can always point people to a blog post in case I ever get asked the same thing again.
Now, what opinions are worth sharing? I’m sure the answer to that question varies from person to person. In my case, I’ve been sharing both requested and unrequested opinions on things I care enough (at least at the time) about.
Of course, opinions can change. If I change my opinion on something, I’ll probably blog about it.
My bottom line is: since I started writing down my thoughts on a number of things people ask me, I haven’t run out of ideas on what to post about. People can always ignore/delete a post. I can always go back to my posts to think about my progress on certain aspects of things I do. Some of my posts may get my readers to think about things they weren’t thinking of before. If one post is ignored by 1000 people, but helpful to a single person (which could even be myself!), then post was already worthy.
And the next time I’m thinking whether something is worth a blog post or not, I’ll think of this piece of Internet Wisdom: