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

Unless it is a general annotation.

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.

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.

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

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

Dim Foo '@Exposed

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

Or at least on a separate line.

Still, some scoping issues cannot really be avoided.

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

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.

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

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

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

MultipleProcedureOnOneLineInspection?

It would apply to both.

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

Actually, I am not sure whether that is legal.

No it is not legal to have multiple default members

Somehow I think End Sub makes the colon illegal.

hmm that's convenient.

Tested it, it is illegal.

I didn't know that

yes, same here.

One headache less.

Thank goodness.

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

Ok, I will ignore case 2.

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

That rule is stupid.

^

No, that will not work.

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

Makes sense.

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

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.

I do wonder if there should be MissingWhitespaceBetweenProcedureInspection and CommentsAtEndOfProcedureInspection.

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

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

It just annoys me.

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

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.

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.

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.

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

@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.

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

They'll guard me from bad code.

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

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.

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

so I think that is fine by me.

It will be an int?.

Annotations on non-whitespace will not annotate anything.