VBA Rubberducking

« first day (1655 days earlier) ← previous day next day → last day (1525 days later) »

Mathieu Guindon

22:00

TBH, as long as IllegalAnnotationInspection correctly reports all misplaced and/or misused annotations, I'm fine with whatever scoping rules we come up with

M.Doerner

Unless it is a general annotation.

this

Right but at least we get consistent behavior, even if we don't have a separator line between the declares, and it does not contradict what VBE does show with separator, I'm happy.

M.Doerner

The benefit of this more lax scoping rule would be that we can avoid any problems when adding or removing annotations to members.

Btw, I just verified that the procedure separator really depends on the logical line.

this

yeah, things will get tricky when it's all crammed together.

M.Doerner

I guess it is ok if I make module annotations on module mvariables illegal, right?

Dim Foo '@Exposed

this

22:05

I would think so. they should be putting it at the top of module anyway

M.Doerner

Or at least on a separate line.

Still, some scoping issues cannot really be avoided.

this

yes. we don't currently share any annotations between module and member anymore, right?

M.Doerner

If you write incanvenient code, the scoping will be odd.

I don't think so.

@MemberAttribute VB_VarDescription "Desc"
Dim foo As Variant, bar As Long

That will apply the annotation to both variables.

this

what I was commenting earlier about the logical line and end of statement ---

Case #1:
    Public Sub foo()
    End Sub
    -------
    '
    '
    Public Sub bar()
    End Sub


Case #2:
    Public Sub foo()
    End Sub
    '
    --------

    '
    Public Sub bar()
    End Sub

Case #3:
    Public Sub foo()
    End Sub
    ------

    '
    '
    Public Sub bar()
    End Sub

M.Doerner

'@DefaultMember
Sub Foo : End Sub : Sub Bar
End Sub

this

22:10

In that case, @DefaultMember could only possibly apply to the Foo.

Comintern

MultipleProcedureOnOneLineInspection?

M.Doerner

It would apply to both.

this

I would say they get what they deserve for abusing colon.

M.Doerner

Actually, I am not sure whether that is legal.

this

No it is not legal to have multiple default members

M.Doerner

22:11

Somehow I think End Sub makes the colon illegal.

this

hmm that's convenient.

M.Doerner

Tested it, it is illegal.

this

I didn't know that

yes, same here.

M.Doerner

One headache less.

this

Thank goodness.

i guess whoever wrote the specifications realized they'd get in so much trouble with colons and the End <procedure>

M.Doerner

22:13

Ok, I will ignore case 2.

Comintern

I'm assuming this works? Sub Foo(x): Debug.Print x: End Sub '@DefaultMember

M.Doerner

That rule is stupid.

Comintern

M.Doerner

No, that will not work.

No annotations on the same logical line as anything non-whitespace.

Comintern

Makes sense.

this

22:15

the case 2 does contradict what the separator suggests, though.

M.Doerner

Currently that would work, if there was a member right below.

I think that case is an artifact of how attribute scoping works.

The attributes have to start at the first line below the first line of the member.

this

I do wonder if there should be MissingWhitespaceBetweenProcedureInspection and CommentsAtEndOfProcedureInspection.

Comintern

Oh, F*ck me. This is legal:

Type Foo: Bar As String: Baz As String: End Type: Enum Alpha: A: B: C: D: End Enum

Sub Noooo()
    Dim x As Foo
    Debug.Print Alpha.B
End Sub

M.Doerner

I really never realized how strange the separator behaves because I have it always turned off.

It just annoys me.

Comintern

Apparently it's no holds barred in the declarations section.

this

22:19

Granted. It's weird but it's the default, too, so it concerns me if our annotations don't conform to it.

@Comintern yeah, it's a awful place to be.

M.Doerner

Since we do not allow annotations on or in members, I do not see a problem.

I really would not expect an annotation to be scoped to the member right above, if I cannot put it anywhere in the member.

Comintern

Option Explicit: Type Foo: Bar As String: Baz As String: End Type: Enum Alpha: A: B: C: D: End Enum: Enum Nums: One: Two: End Enum: Dim ws As Worksheet: Const CONSTANT As String = "Foo"

Can do the entire thing on one line.

M.Doerner

If you put an annotation on top, it will apply to all of them.

this

@M.Doerner I actually agree. I suppose if there's an inspection as I suggested to call out weird-placed annotations, that might encourage them to keep the code consistently formatted.

i just don't like it contradicting what the procedure separator line suggests.

IvenBach

I've started looking at getting more rubber ducks. The outlook is starting to get pricey.

They'll guard me from bad code.

Mathieu Guindon

22:40

Bwahaha every year I get free MSE rep out of this one

A: What are the fantasy secret hats you'd wish to get?

BINGO! Earned all hats in the same row, column, or diagonal. Hats are arranged in a grid with 5 columns (B-I-N-G-O). Clear a row, column or diagonal and say "BINGO!". Only awarded once per user. I realize this one stands no chance against Darth Vador, Gandalf, or even a LEGO brick. But loo...

M.Doerner

23:13

Would it be OK to put the annotation line on the annotation itself?

I mean the line it would apply to.

And for module annotations the line the line that determines whether it is above the first member.

I could determine it from the context in the processing, but putting it an the annotation would probably cause the least pain trying to get decent performance.

this

that would also conveniently eliminate all the edge cases where separators contradict the position/apparent scope

so I think that is fine by me.

M.Doerner

It will be an int?.

Annotations on non-whitespace will not annotate anything.