Skip to content
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

Add a draft for a standard module style guide #17675

Merged
merged 2 commits into from
May 13, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions doc/rst/developer/bestPractices/StandardModuleStyle.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
Standard Module Style
=====================

This document describes general guidance for style when writing a
standard module. Of course there will be exceptions to this guidance when
there is a good reason.

PascalCase and camelCase
------------------------

Prefer PascalCase or camelCase to separating_with_underscores. The rest
of this document will use PascalCase or camelCase to signify the pattern
of indicating new words with an upper case letter and starting the
identifier; where PascalCase starts the name with an upper case letter
and camelCase starts with a lower case letter.

Modules
-------

Module names should be PascalCase.

.. note::

Chapel does not use a separate namespace for types vs. module names. As
a result, it's generally a goal to avoid using the same name for, say,
a type and a module.

Classes
-------

Class type names should be PascalCase. The idea is that starting with an
uppercase letter is the convention for by-reference types.

Records
-------

Record type names should be camelCase. The idea is that starting with a
lowercase letter is the convention for by-value types.

Enums
-----

Enum type names should be camelCase. The enum values should also be
camelCase.

Functions and Methods
---------------------

Function and method names should be camelCase.

Generally speaking, it's desireable to use methods on a value (vs
functions that aren't methods) when there is a clear type responsible for
the operation.

Use parentheses-less methods only for returning properties that could be
reasonably implemented as fields. However, if such a method is named
named isXYZ or hasXYZ it should use parentheses (so, use
`proc isReal() { ... }` rather than `proc isReal { ... }`).
Parentheses-less functions that aren't methods should be avoided.

Many paren-ful methods take some notable action. Try to make these
methods method names be a verb. In particular, a method that modifies an
argument in-place should be a verb.

Other Identifiers
-----------------

Variables, fields, and argument names should be camelCase or CamelCase.