Reading code

“When I get a Code Review request, I always open it. If it is a one line change, I click ‘Looks Good’, otherwise I’ll close it and let someone else deal with it”
Derek

Derek said this in jest, but the thing is, it is actually true. Derek avoids doing Code Reviews because he just wants to write code, or simply chill out. Or that was my interpretation anyway.

Developers should always partake in Code Reviews. It helps enforce Coding Standards, and helps your team learn from each other. It’s also mandatory for our code to be approved before we can commit it, so it’s good if is done promptly.

It winds me up that Derek never does them (well, it’s a rare event). It was part of his job as a Developer, but he is a Senior; so it is definitely part of his job.

Anyway, shortly after moving over to Git source control, Derek calls me over and asks me how he can grab the code from the Pull Request (Git’s nomenclature for Code Review) so he can test it out himself. I was quite shocked he actually was looking at one. Anyway, he comes out with this quote for the reason he wanted to test the code out:

“Some people are better at reading code and understanding it than others”
Derek

He was stating a reason he doesn’t do Code Reviews is that he finds it difficult to read code, and can only really understand it if he can step through it using the debugger.

The thing is, reading code is a major part of what a developer does. I think it’s a huge struggle if you can’t work things out and picture how it pieces together simply by reading. Sure, debugging does help, and is required with more complex and abstract areas… but; a Code Review is usually a small change. The changes are clearly highlighted with the editor with a Before and After view, with the colour Green showing additions and Red showing deletions. It will be linked to a Bug report so you know the Developer’s intention. They will (or should) have written a good Commit Message which will show in the History when they check it in. What extra help does he really want/need?

Mini Musing #2

When talking about the Source Control “Git”, there’s so much jargon to throw around. Pull, Push, Fetch, Sync, Clone, Stage, Rebase, Squash, Branch, Merge, Commit, Tag…

I was talking to the Junior Developer about Git, and he comes out with this gem:

“When I think about Git, it reminds me of the game Bop It!”

“Fetch It”, “Pull It”, “Push It”

Commit Messages

Now that we have moved to Git, our Lead Developer seems to be making more of an effort to promote good “commit” messages. Over the last few months, we have joked about the quality of some of the commit messages in TFS, and how useless and frustrating they are.

“Fix bug 1756”
“Address code review comments” 
“correct previous check-in” 
“fix crash”

All of these don’t describe what has happened, or why the code has changed. With any code change, you always know it has happened to fix a problem, be it: a crash, performance issue, or refactoring to make the code easier to read.

There’s plenty of times when I’ve been investigating a bug, and you track it down to a particular file. Then you view the history of the changes to try and understand at what point the bug was introduced. When you are greeted with any of the examples stated above, then you have to look at each change and look at the linked Work Item (Bug Report). It’s great when you can just glance at the commit messages and can jump straight to the most likely culprit.

Say you are investigating a issue with Threading and you see:

“Minor refactoring of the DisplayInfo method”
“Change threading to use a threadpool” 
“Add null check to prevent crash after clearing data”

You can then just jump straight to the change that clearly states there’s a change regarding threading.

I overheard the Lead Developer tell Derek to write a detailed commit method for his latest change and he says “seriously? I never write a detailed commit message; linking a Work Item is enough”.

I was face-palming. Surely, with a few months development experience, you will learn that good commit messages are very helpful. You could argue it only saves a few clicks and a few minutes here and there; but why make your job, or other people’s jobs harder?

Useless Git

As part of my employer’s technology refresh, we will now be using Git as our source control (alongside Azure DevOps), moving on from Team Foundation Server (TFS).

Although using Git requires a different way of thinking, it is still a type of source control, so the same steps of checking out code, making changes, and checking in still applies.

I get into work, click a few buttons to “Clone” the source (it took around an hour for that to complete though), then click a few more buttons to set up a branch. Since I had been making changes before the switch-over, I then copied my changes that I had been doing in TFS into my Git repository. After 2 hours, I had my code uploaded to the server and had a decent understanding of the process.

Today, Derek was doing the same process, and by the end of the day, he had finally sent his “Pull Request” (Code Review in TFS terms)…with the assistance of the Lead Developer. He then exclaims “that’s a fairly successful first attempt”, then goes home.

Sorry to disappoint you Derek, but this is a trivial process which took you 5.5 hours longer than me, and required assistance of the Lead Developer.

Mini Musing #1

In C#, when you create a Winforms form, you get a “.cs” file where you can write your own code, then a “.Designer.cs” file which is autogenerated. Every time you make a change using the Design View, it will regenerate the “.Designer.cs” file, so you should never manually change it.

    #region Windows Form Designer generated code

    /// <summary>
    /// Required method for Designer support - do not modify
    /// the contents of this method with the code editor.
    /// </summary>
    private void InitializeComponent()

As you see in the example, it has a region which says “generated code“, then the next part is a comment that says “do not modify the contents“. So even if you don’t previously know it’s a generate file (as I described in the first paragraph); you sure do now.

Today, I got a code review where the InitalizeComponent method had been manually changed. Idiots.