Casing for private const and private static readonly

[BrightLight]

What is the proposed casing for private const or private static readonly?
According to AV1702, constant field and static readonly field should be Pascal cased, private fields should be camel cased.
Is there somewhere a statement that says which one takes precedence?

[dennisdoomen]

A const field should always be in Pascal casing.
A private non-constant field should use Camel casing
A public field should use Pascal casing (although I try to avoid those)

Whether or it it is static or readonly is irrelevant IMO

[bkoelman]

I'm interpreting AV1702 like this:

identifier	subtype	casing
field
	private	x
	* (public, internal, protected, private protected)	X
constant		x
	local	x
	* (field: public, internal, protected, private protected, private)	X
static readonly field
	private (!!!)	X
	* (public, internal, protected, private protected)	X

private static readonly field is the exception here. (Non-private static readonly fields are already pascal-case due to other existing rules.) Why the exception? It was commonly used for fields that were intended to be constants, but could not be for technical reasons. So we made them look like constants as much as possible. Call them "functional constants" if you like :) constant casing wins over field casing here.

We may remove the exception like Dennis suggests above, but I would advise against changing. Because such a change creates a lot of churn in existing code bases, while it's ultimately just a matter of taste.

Instead, the tweaks I would like to propose to clarify AV1702:

1. change readonly static field to private static readonly field (non-breaking)
2. change protected field to non-private field (non-breaking)
3. re-order the table such that private static readonly field and constant are above other field rules (non-breaking in my interpretation)
4. Below the table, add a note that order of precedence is from top to bottom: higher wins (removes ambiguity)

[dennisdoomen]

I based my answer on the R# defaults ;-)

[bkoelman]

I believe this issue can be closed now (but I have no rights).