Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

I’m curious to know how folks deal with comparative code reviews (version x against y of a file) in the presence of strong type inference, that is when ‘var’ (in C#) or ‘auto’ (in C++ 0x) is used in place of the older more verbose (explicit) type declaration.

When IntelliSense is available one can just float the mouse over the keyword to determine (if necessary) the inferred type – but what do folks do when viewing such sources in Notepad or Code Collaborator etc.

Of course strong type inference predates C# and C++ by decades, so how do folks in other languages that have had the feature for years cope? I’m inclined to think that the right hand side of the assignment expression is where most bugs are to be found.

share|improve this question
1  
This might garner a better response on Programmers SE. – chrisaycock Apr 25 '11 at 20:01
I would recommend that the actual review of the code be done in a modern IDE, even if the annotations are being put on a printed copy. In addition to verifying type inference, the navigation features and tools for analyzing usages are extremely valuable when reviewing code. – Dan Bryant Apr 25 '11 at 20:14
If the type inferred has changed, it must be due to some other change in the code, focus on that part and determine whether it makes sense or not. Type inference there only helps in reducing the amount of changes that are required. – David Rodríguez - dribeas Apr 25 '11 at 20:30

migrated from stackoverflow.com Apr 25 '11 at 22:14

2 Answers

up vote 1 down vote

I don't want to spend my time in a code review doing static analysis. In fact I've always insisted on paper reviews. I want concentrate on seeing if the code looks good and solves the problems it is addressing. And I want the the review process to train up junior staff.

share|improve this answer
up vote 1 down vote

If you are comparing version x against version y, wouldn't you be using some kind of a diff tool to look at the differences? The trick is to commit changes often, so that each change set is small and can be easily understood and verified for correctness. Making your functions and classes small would also help.

It would seem that this issue is not specific to code review. Type inference would present the same difficulties for writing the code in the first place, and for debugging. The solution to these problem is using good programming practices. Be disciplined, refactor your code to make sense, take small steps when you change your code, and test it after each change.

share|improve this answer
The problem is that if you're looking at "var x = Foo();" and the return type of Foo has changed then a simple diffing tool will not show this in-situ. Whereas "int x = Foo();" changing to "double x = Foo();" gets highlighted. – Tom Kirby-Green May 5 '11 at 11:56
Sure, the compiler will not produce an error for var x. But still, if changing the return type of Foo() causes a problem, it should show up in a unit test. Then you look at the recent changes, and determine that the change of the return type of Foo() is the cause. And if you don't have any unit tests, then you should write some. – Dima May 5 '11 at 14:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.