Feathers coding conventions for contributors

This is the code formatting style used within the Feathers library. When contributing code to Feathers, you are required to use this style. Pull Requests to the Feathers project on Github that are formatted with a different style will be rejected. The author respects that you may have your own personal style, and the author would attempt to follow your style if he were to contribute to your open source project. Save him some time so that he doesn't need to manually reformat your contributed code.

If you are not contributing code to Feathers, then please feel no obligation to follow this style guide when working with the library. This guide is aimed at developers who wish to contribute bug fixes and enhancements to Feathers.

The terms "public" and "private" are used below in a general sense. When the specific public or private namespace is referenced, it will be clearly styled. When not marked as a namespace, public refers to any API that is meant to be exposed to someone using a particular class. It may include things like public members and protected members that are meant to be accessed in subclasses. Similarly, private refers to APIs that are meant to be used only internally. Private APIs may be part of the protected namespace, but using these APIs in subclasses is an at-your-own-risk convenience only.


Line Length



Access Levels

Class Organization

In general, classes should be organized in the following manner:

  1. static Variables

  2. static Functions

  3. Constructor

  4. Member Variables and Properties

  5. public Member Functions

  6. protected Member Functions

  7. private Member Functions

Additional Notes on Class Organization

The this keyword

The this keyword should be used to reference member variables and functions. The author is particularly serious about this one, in case you didn't notice when you looked at the Feathers source code.