Contribution Guideline

[0xferit]

As discussed in #324, we should write up a contribution guideline to make it easier to contribute and review.

Rules that are enforced by test cases are marked with an asterisk * and #328 will add the initial set of tests.

Updated 2018-02-04 by Andreas:

Coding Conventions

• Match the existing code style, we generally stick to "Visual Studio defaults" and .NET Foundation Coding Guidelines
• If you use ReSharper there is a settings file that will take effect automatically
• There is an .editorconfig to configure whitespace and some C# syntax
• Add the file header to new files you create

Test Code

• Test class: Use Tests suffix for the type you are testing, such as UnitSystemTests
• Test method: <method>_<condition>_<result> (Parse_AmbiguousUnits_ThrowsException)
• If there are many tests for a single method, you can wrap those in an inner class named the same as the method and then you can skip that part of the test method names

Unit definitions (.JSON)

For a fairly complete summary of the unit definition JSON schema, see Meter of Length. It has prefix units and multiple cultures.

Conversion functions

Converting from unit A to B is achieved by first converting from unit A to the base unit, then from the base unit to unit B. To achieve this, each unit defines two conversion functions.

• Prefer multiplication for FromUnitToBaseFunc (x*2.54e-2 for Inch to Meter)
• Prefer division for FromBaseToUnitFunc (x/2.54e-2 for Meter to Inch)
• Prefer scientific notation 1e3 and 1e-5 instead of 1000 and 0.00001
• Prefer a constant if the conversion factor is finite (x*2.54e-2 for Inch)
• Prefer a calculation if the conversion factor is infinite ((x/72.27)*2.54e-2 for PrinterPoint)

Units

Generally we try to name the units as what is the most widely used.

• Use prefix for country variants, such as ImperialGallon and UsGallon

Note: We should really consider switching variant prefix to suffix, since that plays better with kilo, mega etc.. Currently we have units named KilousGallon and KiloimperialGallon, these would be better named KilogallonUs and KilogallonImperial.

Unit abbreviations

A unit can have multiple abbreviations per culture/language, the first one is used by ToString() while all of them are used by Parse().

• Prefer the most widely used abbreviation in the domain, but try to adapt to our conventions
• Add other popular variants to be able to parse those too, but take care to avoid abbreviation conflicts of units of the same quantity
• Use superscript (cm², m³) instead of cm^2, m^3
• Use ∆ for delta (not ▲)
• Use · for products (N·m instead of Nm, N*m or N.m)
• Prefer / over ⁻¹, such as km/h and J/(mol·K)
• Use h for hours, min for minutes and s for seconds (m is ambiguous with meters)
• Use suffixes to distinguish variants of similar units, such as gal (U.S.) vs gal (imp.) for gallons
  • (U.S.) for United States
  • (imp.) for imperial / British units

[angularsen]

I guess the obvious one is to at least link to here:
https://github.com/angularsen/UnitsNet/wiki/Adding-a-New-Unit

There is a (rather small) section on Code Style there, as well as some bullet points on conventions for JSON functions and test code when adding new units.

A couple of other things I can think of:

• Add the library's file header to new files you create
• Test method naming convention (it varies today)
• Special symbols:
  • ∆ for delta
  • Use superscript (cm², m³)

Anything else? What inconsistencies did you notice in the existing code?

Usually people follow the existing code style fairly well and when adding new units it's very little new code to add, so it's not been a big issue fortunately.

[jnyrup]

We could add an [.editconfig](http://editorconfig.org/) to help having a consistent code style.
It is supported on numerous editors and can have different code style for .cs and .json files.

Regarding superscripts, we could test it.
If it were to be pretty, it would be an analyzer that generated a compiler error, if a superscript was not used.
The easy way to get the job done is to make a unit test that checks that no abbreviation in UnitSystem matches '\D\d'. Currently that catches AreaMomentOfInertiaUnit having both cm⁴ and cm^4 as abbreviations.

[angularsen]

Good idea, a .editorconfig file would be helpful. I propose we use or adapt Roslyn's file: https://github.com/dotnet/roslyn/blob/master/.editorconfig

A unit test to catch missing superscript, wrong delta symbol etc could be useful and should be easy enough to write, although hopefully we do catch these things in PR review when the guideline is set.

[jnyrup]

With good enough reviews unit tests are never necessary, but I wouldn't rely on humans being omniscient reviewers.

[angularsen]

Fair point!

[jnyrup]

There should probably also be some conventions about notation when writing abbreviations:
We have two different notation is used when the denominator is a product:

MolarEntropyUnit.JoulePerMoleKelvin
    J/(mol*K)

SpecificEntropyUnit.CaloriePerGramKelvin
    cal/g.K

Some units have different capitalisation across abbreviations:

• British thermal unit is abbreviated BTU and Btu.
• hour is abbreviated hr, Hr and h
• second is abbreviated S and s

Some units are in plural while others aren't.

• Flow has e.g FlowUnit.CentilitersPerMinute
• Molarity has e.g. MolarityUnit.CentimolesPerLiter

When prefixing a unit with e.g kilo the unit should be lower case:

• ForceUnit.KiloPond
• BrakeSpecificFuelConsumptionUnit.GramPerKiloWattHour

Check that Milli is not spelled Mili

• MassMomentOfInertiaUnit.KilotonneSquareMilimeter
• MassMomentOfInertiaUnit.MegatonneSquareMilimeter
• MassMomentOfInertiaUnit.TonneSquareMilimeter

[gojanpaolo]

Should there also be a convention when describing Area and Volume in other units (i.e. if the power should be used as a prefix or suffix of the unit)?
This is brought up with regards to this PR #364 to add AreaDensity and ElectricChargeDensity. Both units used the power as a prefix (KilogramsPerMeterSquared and CoulombPerMeterCube).

[gojanpaolo]

Convention for country suffix of units?
e.g. USSurveyFeet

• ft (US)
• ft (U.S.)
  ...

See also PR #361 (comment)