Selfelected

Code reviewing comments

I am presently using TFS’s code reviewing tool and IMHO it lacks visualisation of which comments are important and which are not.

So I came up with the idea of prefixing my comments.

PRAISE: Good refactoring, I like how you remove the negation.

FIX: A null check is missing.

SUGGESTION: Split line.

CHECK: Is it the right enum used here?

EXPLAIN: Is this comparison really correct? or seems to overflow to me.

If there are many FIX but only one or a few are critical I prefix the critical once with RED, like RED FIX.
This gives the opportunity to “while you already are updating the module, do these things too”.

When code reviewing do not forget to give appraisal too

Update:

This is what I wrote at Patricia Aas’ show at Dotnetrocks:

I have learned that some don’t like code review because it is a critique of the code written. When failing a code review the task is halted for a rewrite and everyone loses.

I love it because to me it is a discussion about code and the system *we* are building *together*.
The code involved is a talking piece.

I prepend my comments with “PRAISE:”, “FIX:”, “SUGGESTION:”, “EXPLAIN:” and “CHECK:”.

FIX is the only one failing a code review.
Depending on the amount of, and severity, EXPLAIN and CHECK might give a red flag too.
The rest are for discussion; to learn and spread knowledge.

PRAISE is important. Only giving negative critique wears a relation. It might also be a part of the reason some don’t like code reviews. It can be hard to recognise good code as, as with many things, it steps out of the way so one does not reflect upon it. Good naming of a method, remember to remove old usings, good test data, …

SUGGESTION is how *I* would like to write the code. Change if you like, don’t if you don’t. I’d be happy to talk about it but there is no need to involve me in a decision.

EXPLAIN on the other hand requires my input. I don’t understand what you are doing – please explain it to me. If it is easy to explain then I should probably have understood; but if you have a hard time explaining it, then there is a good chance the code is too complex. (I have found a bug this way.)

CHECK is more serious. I am not sure you are doing the right thing and would like for you (or anyone else, including me) to double check it.

Typically there will be quite some SUGGESTION followed by a healthy amount of CHECK and EXPLAIN.

Update:

I have used this method for some projects now and only received positive or neutral feedback.

In one project one colleague took every SUGGESTION and implemented them while another ignored anything that wasn’t FIX. Both were skilled and made good choices. We talked a lot about code.

In another project my colleague liked to start with only looking at FIX to get a tally and then read through the rest. S/he is/was junior and we’ve had good discussions about code.

Update:

Someone else has come to the same conclusion: https://conventionalcomments.org/#labels

When code reviewing – do not forget to give appraisal too

Albeit code reviewing is for the greater good and we all adhere to the idea of common ownage of code we are still critisising someone else’s labour.

Psychologically we cannot neglect that.

Ergo: remember to tell about the good solutions and code you find.

Unfortunately TFS does not have a (good) solution for differentiating between comments and praise and critisism.

Microsoft team foundation bug management

A minute ago I reported two bugs for a project and noticed that the GUI for bug reporting in TFS inside Visual studio still sucks.  It sucked 5? years ago.  It still does.

It was a flashback because I 1) didn’t remember exactly how user unfriendly the form is with edit fields all over, hard (partly impossible!) to navigate with keyboard and bad overview.  There wasn’t a clue 5 years ago that a bug had an attachment.  There still isn’t.  2) didn’t remember how awfully slow it was.  Reporting bugs might inflict some stress to me because there is so much I want to tell but text and images are so limited and I want to get it all out before it flees my mind.

Now I can see that the overview of bugs is still lousy.  I have read that it has improved but from what?  To Microsoft’s defense I must say that they have done a good effort but it all smells like one-department-for-testing with dedicated-testers and one-department-for-developers and so on.  To me development, testing, operations, architecture is all the same.

So even though I like the symbiosis of TFS and VS and the whole test rig with virtual machines one can buy from Microsoft I won’t sell the bug management tool to any client that isn’t already deep into it.
The licensing model, as I remember it last time I checked, also bothers me but that is for another article.

Running two version managers against one solution

Since I have been having problems with reaching my company’s TFS server from home I started with SVN.  One could say I use SVN as an offline SCM.

#1: Don’t use Visual studio for both version managers in the same solution.

Visual studio takes for granted one solution is against one SCM.  Swapping TFS and SVN messes everything up.

#1.1: Use Visualstudio with TFS and SVN with explorer.

I don’t think there is a TFS tool for explorer so the other way around is not possible.  This means I checkin TFS from Visual studio and commit SVN from explorer.

#2: Stuctural changes take time.  And possibly ruins the history.

I don’t try to keep the SCMs in sync but instead have the TFS as main repository.  I make sure folder moves etc. are done properly in TFS and then just reset (get everything – commit whatever it looks like) in SVN.

With these caveats sorted out it works nice.