New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable naming conventions #380

Open
retailcoder opened this Issue Apr 15, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@retailcoder
Member

retailcoder commented Apr 15, 2015

Somewhat related: #31

Rubberduck could let users configure naming conventions, and have inspections to enforce them.

I can think of a number of ways to specify a naming convention:

  • Casing (UPPERCASE, lowercase, PascalCase, camelCase, snake_case)
  • Prefixes (m_, p, a, etc.)

..and a number of identifier types to define the naming conventions against:

  • Public fields (global-scope)
  • Private fields (module-scope)
  • Constants
  • Procedures ("sub")
  • Functions ("function")
  • Properties ("property get/let/set")
  • Parameters
  • Local variables

So, a naming convention could be defined like:

  • [Public fields] should be [PascalCase]
  • [Private fields] should be [camelCase] [prefixed with 'm_']
  • [Constants] should be [UPPERCASE]
  • [Procedures] should be [PascalCase]
  • [Functions] should be [PascalCase]
  • [Properties] should be [PascalCase]
  • [Parameters] should be [camelCase] [prefixed with 'p']
  • [Local variables] should be [camelCase] [prefixed with 'a']

And then there could be inspections (a new NamingConventions inspection type would need to be created) that would fire up an inspection result for any declared identifier that doesn't follow its naming convention.

The settings dialog would need a new page to:

  • Enable/disable naming conventions
  • Configure naming conventions

I suggest to bake the following conventions as default:

  • [Public fields] should be [PascalCase]
  • [Private fields] should be [camelCase]
  • [Constants] should be [UPPERCASE]
  • [Procedures] should be [PascalCase]
  • [Functions] should be [PascalCase]
  • [Properties] should be [PascalCase]
  • [Parameters] should be [camelCase]
  • [Local variables] should be [camelCase]

I'd also make one that recommends encapsulating class module private fields into a private type, and only having one private field in a class, called this - but that might be pushing it.

@rubberduck203

This comment has been minimized.

Member

rubberduck203 commented Apr 15, 2015

I think this is a wonderful idea, but considering that VB6 is case insensitive, I'm skeptical about how well this will work in practice. I'm interested in seeing this happen, but am also glad to see you've already planned on a way to let the user disable it.

@UnhandledCoder

This comment has been minimized.

UnhandledCoder commented Jul 23, 2017

I would like to ask you to review/participate my idea regarding namings and if it maybe would be possible, to add those (or similar) rules, maybe configureable, to RD:
https://stackoverflow.com/questions/45278189/reliable-vba-source-code-management-regarding-case-insensitivity-and-auto-renami

@retailcoder

This comment has been minimized.

Member

retailcoder commented Jul 24, 2017

@UnhandledCoder Stack Overflow isn't a good place for that discussion, which is inherently opinionated.

In fact, there's a reason this issue has been open for so long: I don't believe in (most) prefixes, and IMO if you're reusing a name in a different case than what it was originally used for, then the solution is to find a better name, not to prefix it with some random character.

Seems this feature goes against the spirit of HungarianNotationInspection, at least if it allows configuring prefixes (and enforces them). ...so I'm kind of on the fence about whether this feature would be a good or a bad thing.

@UnhandledCoder

This comment has been minimized.

UnhandledCoder commented Jul 24, 2017

I absolutely agree. finding good names is the base of all.
But what about such a sample:

Private Type TFoo
    Car As ICar
    '...
End Type

Private Sub Bar(ByVal car As ICar)
    '...
End Sub

In that simple situation we have the problem with the spelling of c|Car.
Both, the member- and also the parametername are well named.
To avoid the problem here, I would have to construct an artificial name which just doesn't fit as well.

@retailcoder

This comment has been minimized.

Member

retailcoder commented Jul 24, 2017

Well that's a poor example, because it's so contrived that indeed it looks like it's hopeless. There's always a way, with real code.

@UnhandledCoder

This comment has been minimized.

UnhandledCoder commented Jul 24, 2017

Just a bit contrived. ;-)
In a real project I have this problem with the word "Events".

@retailcoder

This comment has been minimized.

Member

retailcoder commented Jul 24, 2017

If you have real working code with naming issues and/or design dilemmas, consider posting it on https://codereview.stackexchange.com.

@UnhandledCoder

This comment has been minimized.

UnhandledCoder commented Jul 24, 2017

Nice Suggestion. But it's company code, and I would have to abstract it a bit.

@UnhandledCoder

This comment has been minimized.

UnhandledCoder commented Jul 28, 2017

I edited my question into on-topicness (hope so) now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment