Suggestion: Parameter 'CloseMode' can be passed by value - Foundation.SimpleView (Start: L62C52 End: L62C60)
Suggestion: Parameter 'CloseMode' can be passed by value - Foundation.ValueSelectorView (Start: L141C52 End: L141C60)
Suggestion: Function 'ValidateItemType' returns an implicit Variant - Foundation.List (Start: L87C1 End: L92C12)
Warning: Function 'IPresenter_CanExecuteAcceptCommand' returns no value - Foundation.SizeRangeSizesPresenter (Start: L51C1 End: L53C12)
Warning: Function 'IPresenter_CanExecuteAcceptCommand' returns no value - Foundation.SizeRangesPresenter (Start: L62C1 En…
ah, better
...
Rubberduck Code Inspections - 01/03/2015 10:28:31 PM
107 issues found.Warning: Option Explicit is not specified - Foundation.Sheet3, line 1
Warning: Option Explicit is not specified - Foundation.Sheet2, line 1
Warning: Option Explicit is not specified - Foundation.LayoutTypes, line 1
Warning: Option Explicit is not specified - Foundation.Sheet1, line 1
Warning: Option Explicit is not specified - Foundation.LogSheet, line 1
Warning: Option Explicit is not specified - Foundation.StringHelpers, line 1
Rubberduck Code Inspections - 01/03/2015 10:38:14 PM
12 issues found.
Warning: Parameter 'bar' is passed ByRef implicitly - VBAProject.Module1, line 2
Hint: Parameter 'bar' is not used - VBAProject.Module1, line 2
Warning: Function 'DoSomething' returns no value - VBAProject.Module1, line 2
Error: Variable 'foobar' is never assigned - VBAProject.Module1, line 3
Hint: Variable 'foobar' is never used - VBAProject.Module1, line 3
Suggestion: Parameter 'bar' can be passed by value - VBAProject.Module1, line 2
Rubberduck Code Inspections - 01/03/2015 11:13:28 PM
2 issues found.
Suggestion: Member 'DoSomething' is implicitly Public - VBAProject.ThisWorkbook, line 1
Warning: Option Explicit is not specified - VBAProject.ThisWorkbook, line 1
Currently, the .NET Framework 4.5 runs only on Windows 7 and above:
Operating system Version 4.5 Beta
--------------------------------------------------------
Windows 8 Consumer Preview √ (see notes)
Windows 7, all editions √
Windows Vista,...
> Currently we're targeting the 4.5 framework, which is not supported by Windows XP. We can add support by targeting the 4.0 or 3.5 framework. We need to determine the minimum version necessary and target that instead. Obviously, 3.5 gives us maximum compatibility, but I'm not sure if/what features we're using that wouldn't be available.
[List of Operating Systems Supported by 4.0 and 3.5](https://msdn.microsoft.com/en-us/library/8z6watww(v=vs.100).aspx).
In the .NET Framework 4.5, new asynchronous features were added to the C# and Visual Basic languages. These features add a task-based model for performing asynchronous operations.
> After further investigation, we might not want to target anything older than 4.5. We're using the async features that were introduced in 4.5. Sticking with 4.5 means the minimum OS for Rubberduck would be Vista. Considering XP has reached the end of it's lifecycle, I'm not sure we should uproot the code base to support it. On the other hand, there are many users out there still using XP, as evidenced by the user who brought this to our attention. Thoughts @retailcoder?...
> I don't think disabling the TPL & async code for a < 4.5 target would make a good UX. And not leveraging async/await and the Task Parallel Library means we need to implement multithreaded code ourselves.
Windows XP is out, officially not supported since almost a year now - we know our code can run on a Vista+Office97 setup, I don't think it's worth the effort to go out of our way to retarget for 4.0.
I don't know why some companies wait until the last minute. I would think it would make more sense to upgrade as soon as better technology is available (in a stable release)
@GregBurghardt I know, this entire code builds on ADODB parameterized queries (BTW this is VBA, not .NET)... if you looked at how this code is used, you realize that it generates the parameters for you, so SqlCommand.SelectSingleValue("SELECT SomeField FROM SomeTable WHERE SomeValue = ?", 123) is all you need to code to get a full-fledged parameterized query, without the hassle of creating the parameters yourself. — Mat's Mug23 secs ago
I'd use Skip: as a label name. GoTo is being used for making up for the lack of a Continue statement in VBA - I think that's one of the few legit uses of GoTo. Also, readability could be further improved by extracting methods from the loop's body. — Mat's Mug5 secs ago
Public Sub Main()
' Given List properly implements ICountable And IPrintable
WillFail List.Create(1,2,3)
End Sub
Public Sub WillFail(ByVal x As ICountable)
If TypeOf x Is IPrintable Then
Debug.Print x.ToString
End If
End Sub
if x is a List then TypeOf x Is Printable will return true, but x.ToString will fail because ICountable doesn't implement ToString. So x both is and is not IPrintable...
> The TypeOf operator determines whether the run-time type of objectexpression is compatible with typename. The compatibility depends on the type category of typename. The following table shows how compatibility is determined.
Yes yes. But what if your whole damn system lies at that outer boundry Uncle Bob?
> Mocking the interactions between all classes forces you to create mocks that return other mocks (that might return yet other mocks). You have to mock out all the data pathways in the interaction; and that can be a complex task. This creates two problems.
The setup code can get extremely complicated. The mocking structure become tightly coupled to implementation details causing many tests to break when those details are modified.
Sounds like mocking out the VBE and ANTLR parser.. ^
@RubberDuck depends what you're testing; I've written tests (not sure if they're still in the solution) that "mock" the VBE by passing a simple string to RubberduckParser.Parse, and verify that the returned parse tree contains what it's expected to contain - that's really testing the grammar and its generated lexer/parser though.
With Moq you can easily set up a mock that replaces a CodeModule and is set up in a way that _vbe.ActiveProject.CodeModule.Lines() returns a predetermined string.
or whatever
Personally I find unit testing that is quite a waste of time though.
it was good for understanding the parse tree structure until I realized that it matched the grammar rules exactly - now when I need to understand something about the parse tree I look at the .g4 grammar file.
unit testing, say, the extract method refactoring, is overkill IMO. As much as I love being able to write unit tests in VBA, and as much as I like writing testable C# code, actually writing unit tests feels like an unnecessary burden to me. I know, oooh the sinner, right?
;)
TBH the extract method refactoring isn't exactly written in a testable way
Currently, the .NET Framework 4.5 runs only on Windows 7 and above:
Operating system Version 4.5 Beta
--------------------------------------------------------
Windows 8 Consumer Preview √ (see notes)
Windows 7, all editions √
Windows Vista,...
VBA Rubberducking
VBA Rubberducking