Skip to content

Commit

Permalink
📝 (RUMM-41): Force line wrapping at 80 characters in md files
Browse files Browse the repository at this point in the history
  • Loading branch information
xgouchet committed Nov 21, 2019
1 parent 95a9b16 commit 4711eb3
Show file tree
Hide file tree
Showing 2 changed files with 66 additions and 37 deletions.
77 changes: 51 additions & 26 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,21 +7,25 @@ To propose improvements, feel free to submit a PR or open an Issue.

## Submitting Issues

Many great ideas for new features come from the community, and we'd be happy to consider yours!
Many great ideas for new features come from the community, and we'd be happy to
consider yours!

To share your request, you can [open a Github issue](https://github.com/DataDog/dd-sdk-android/issues/new) with the
details about what you'd like to see. At a minimum, please provide:
To share your request, you can open an [issue](https://github.com/DataDog/dd-sdk-android/issues/new)
with the details about what you'd like to see. At a minimum, please provide:

- The goal of the new feature;
- A description of how it might be used or behave;
- Links to any important resources (e.g. Github repos, websites, screenshots, specifications, diagrams).
- Links to any important resources (e.g. Github repos, websites, screenshots,
specifications, diagrams).

## Found a bug?

For any urgent matters (such as outages) or issues concerning the Datadog service or UI,
contact our support team via https://docs.datadoghq.com/help/ for direct, faster assistance.
For any urgent matters (such as outages) or issues concerning the Datadog service
or UI, contact our support team via https://docs.datadoghq.com/help/ for direct,
faster assistance.

You may submit bug reports concerning the Datadog SDK for Android by [opening a Github issue](https://github.com/DataDog/dd-sdk-android/issues/new).
You may submit bug reports concerning the Datadog SDK for Android by
[opening a Github issue](https://github.com/DataDog/dd-sdk-android/issues/new).
At a minimum, please provide:

- A description of the problem;
Expand All @@ -43,42 +47,59 @@ If at all possible, also provide:
- Code sample or test that reproduces the problem;
- An explanation of what causes the bug and/or how it can be fixed.

Reports that include rich detail are better, and ones with code that reproduce the bug are best.
Reports that include rich detail are better, and ones with code that reproduce
the bug are best.

## Have a patch?

We welcome code contributions to the library, which you can [submit as a pull request](https://github.com/DataDog/dd-sdk-android/pull/new/master).
Before you submit a PR, make sure that you first create an Issue to explain the bug or the feature your patch covers,
and make sure another Issue or PR doesn't already exist.
We welcome code contributions to the library, which you can
[submit as a pull request](https://github.com/DataDog/dd-sdk-android/pull/new/master).
Before you submit a PR, make sure that you first create an Issue to explain the
bug or the feature your patch covers, and make sure another Issue or PR doesn't
already exist.

To create a pull request:

1. **Fork the repository** from https://github.com/DataDog/dd-sdk-android ;
2. **Make any changes** for your patch;
3. **Write tests** that demonstrate how the feature works or how the bug is fixed;
4. **Update any documentation** such as `docs/GettingStarted.md`, especially for new features;
5. **Submit the pull request** from your fork back to https://github.com/DataDog/dd-sdk-android .
4. **Update any documentation** such as `docs/GettingStarted.md`, especially for
new features;
5. **Submit the pull request** from your fork back to this
[repository](https://github.com/DataDog/dd-sdk-android) .


The pull request will be run through our CI pipeline, and a project member will review the changes with you. At a minimum, to be accepted and merged, pull requests must:
The pull request will be run through our CI pipeline, and a project member will
review the changes with you. At a minimum, to be accepted and merged, pull
requests must:

- Have a stated goal and detailed description of the changes made;
- Include thorough test coverage and documentation, where applicable;
- Pass all tests and code quality checks (linting/coverage/benchmarks) on CI;
- Receive at least one approval from a project member with push permissions.

Make sure that your code is clean and readable, that your commits are small and atomic, with a proper commit message. We tend to use [gitmoji](https://gitmoji.carloscuesta.me/) but this is not mandatory.
Make sure that your code is clean and readable, that your commits are small and
atomic, with a proper commit message. We tend to use
[gitmoji](https://gitmoji.carloscuesta.me/), but this is not mandatory.

## Coding Conventions

Our repository uses Kotlin, as it is now the recommended language for Android. But because this library can still be used by Java based application, make sure any change you introduce are still compatible with Java. If you want to add Kotlin specific features (DSL, lambdas, …), make sure there is a way to get the same feature from a Java source code.
Our repository uses Kotlin, as it is now the recommended language for Android.
But because this library can still be used by Java based application, make sure
any change you introduce are still compatible with Java. If you want to add
Kotlin specific features (DSL, lambdas, …), make sure there is a way to get the
same feature from a Java source code.

### Code style

Our coding style is ensured by [KtLint](https://ktlint.github.io/), with the default settings. A KtLint check is ran on every PR to ensure that all new code follow this rule.
Our coding style is ensured by [KtLint](https://ktlint.github.io/), with the
default settings. A KtLint check is ran on every PR to ensure that all new code
follow this rule.

Classes should group their methods in folding regions named after the declaring class. Private methods should be grouped in an `Internal` named folding region.
For example, a class inheriting from `Runnable` and `Observable` should use the following regions.
Classes should group their methods in folding regions named after the declaring
class. Private methods should be grouped in an `Internal` named folding region.
For example, a class inheriting from `Runnable` and `Observable` should use the
following regions.

```kotlin

Expand All @@ -98,7 +119,6 @@ class Foo :Observable(), Runnable {
override fun run() {}

// endregion


// region Internal

Expand All @@ -110,15 +130,20 @@ class Foo :Observable(), Runnable {

### #TestMatters

It is important to be sure that our library work properly in any scenario. All non trivial code must be tested.
If you're not used to writing tests, you can take a look at the `test` folder to get some ideas on how we write them at Datadog.
It is important to be sure that our library work properly in any scenario. All
non trivial code must be tested. If you're not used to writing tests, you can
take a look at the `test` folder to get some ideas on how we write them at Datadog.

We use a variety of tools to help us write tests easy to read and maintain:

- [JUnit5 Jupiter](https://junit.org/junit5/): the test runner, quite similar to JUnit4;
- [Mockito](https://site.mockito.org/): a mocking framework to decouple concerns in the Unit Tests;
- [AssertJ](https://assertj.github.io/doc/): a framework to write fluent assertions;
- [Elmyr](https://github.com/xgouchet/Elmyr): a framework to generate fake data in the Unit Tests.
- [JUnit5 Jupiter](https://junit.org/junit5/): the test runner, quite similar to
JUnit4;
- [Mockito](https://site.mockito.org/): a mocking framework to decouple concerns
in the Unit Tests;
- [AssertJ](https://assertj.github.io/doc/): a framework to write fluent
assertions;
- [Elmyr](https://github.com/xgouchet/Elmyr): a framework to generate fake data
in the Unit Tests.



26 changes: 15 additions & 11 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,6 @@

> A client-side Android library to interact with Datadog.


## Getting Started

## Gradle Dependency
Expand All @@ -18,8 +16,9 @@ dependencies {

### Initial Setup

Before you can use the SDK, you need to setup the library with your application context and your API token.
You can create a token from the Integrations > API in Datadog. **Make sure you create a key of type `Client Token`.**
Before you can use the SDK, you need to setup the library with your application
context and your API token. You can create a token from the Integrations > API
in Datadog. **Make sure you create a key of type `Client Token`.**

```kotlin
class SampleApplication : Application() {
Expand All @@ -41,18 +40,23 @@ val logger = Logger.Builder().build()

> TODO document every feature of the Builder
You can then send logs with the following methods, mimicking the ones available in the Android Framework:
You can then send logs with the following methods, mimicking the ones available
in the Android Framework:

```kotlin
logger.d("A debug message.")
logger.i("Some relevant information ?")
logger.w("An important warning…")
logger.e("An error was met!")
logger.wtf("What a Terrible Failure!")
logger.d("A debug message.")
logger.i("Some relevant information ?")
logger.w("An important warning…")
logger.e("An error was met!")
logger.wtf("What a Terrible Failure!")
```

## Contributing
Pull requests are welcome, but please open an issue first to discuss what you would like to change. For more information, read the [Contributing Guide](CONTRIBUTING.md).

Pull requests are welcome, but please open an issue first to discuss what you
would like to change. For more information, read the
[Contributing Guide](CONTRIBUTING.md).

## License

[Apache License, v2.0](LICENSE)

0 comments on commit 4711eb3

Please sign in to comment.