Coding style change proposals

Jun Wu quark at fb.com
Sat May 13 18:40:11 EDT 2017


Similar to smf, I think only the constant name change is worth considering.
Class and function name change are not practical - that will cause too much
pain for extensions without significant benefit (like perf etc).

I think it's similar to Python 3 migration. Given the fact that Python3
migration causes us so much pain, we should probably learn the lesson and do
not make extension authors suffer.

Excerpts from Gregory Szorc's message of 2017-05-13 14:41:34 -0700:
> I'd like to formally propose some changes to the code style in order to
> make the code more readable, similar to other Python projects, and more
> friendly to non-English speakers.
> 
> I think each naming proposal below can be considered independently. So
> please don't wholesale reject this email because you don't agree with one
> part.
> 
> Proposal 1: use underscores in names. Today, our names are
> "anamewithoutanypunctuation." I want to change that to
> "a_name_with_punctuation." This is vastly easier to read, especially for
> non-English speakers and is similar to how the rest of Python does it.
> 
> Proposal 2: uppercase constants. Right now, constants are a mix of
> lowercase with some exceptions using uppercase. I'd like to standardize on
> using uppercase for all constants. Since Python doesn't really have the
> concept of constants, differentiating constants via naming helps reinforce
> that they are not regular, local scope variables. If I see mutation of an
> UPPERCASE variable when doing code review, that's a quick sign that
> something is wrong. It's harder to do that when the name is lowercase.
> Uppercase constants is how most of the Python universe does it.
> 
> Proposal 3: CamelCase class names. Today, all names are lowercase except
> for error classes. I'd like to switch to CamelCase class names. This will
> help differentiate variables and functions from types, which improves
> readability. This is how most of the Python universe does things.
> 
> If we adopt any of the proposals, a question becomes what to do about
> reformatting existing code. We can't easily do that because of API
> compatibility concerns. For internal names, we could certainly do that. But
> for public and more common APIs, we should be conservative so we don't
> break the world. I propose using the new style for new code and updating
> the style for old code when making significant changes. e.g. if you are
> rewriting a function, you would update names within first, then refactor.
> Or, you would refactor, updating names inline, and write a follow-up patch
> to clean up remaining names for consistency. This will result in mixed
> style throughout the code base, which is ugly. But I think we can manage
> until we're willing to take a mass API breakage hit.


More information about the Mercurial-devel mailing list