Coding Style

How to make build a consistent user experience.

This is a early draft to be filled and reviewed more widely.

1. commands

1.1. adding new commands

1.2. naming commands

2. argument

2.1. naming arguments

2.2. common arguments

3. config

4. adding new sections

5. adding new options

6. naming config options

7. output

7.1. general output

7.2. error message

• Error message should fit on *a single* 80 characters line,
• a hint should be provided to point the user toward a solution (78 chars max),

abort: uncommitted changes
("use 'hg status' to list changes")

• error message should **include the offending item** when possible,

abort: push creates new remote head 02793c56c8d3!
(merge or see "hg help push" for details about pushing new heads)

• error should not blindly point to dangerous operation (eg: --force) point to help topic if advise//explanation cannot be provided in the hint space,

• error message should not be punctuated as a sentence. no leading capital, no final dot, (some existing message have a "!").

7.3. color

8. help text