Coding style change proposals

Gregory Szorc gregory.szorc at gmail.com
Sat May 13 21:41:34 UTC 2017


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170513/c23e8336/attachment.html>


More information about the Mercurial-devel mailing list