From 4711eb3c5d431d3677fc432ff064a71fc100ca53 Mon Sep 17 00:00:00 2001 From: Xavier Gouchet Date: Thu, 21 Nov 2019 11:53:46 +0100 Subject: [PATCH] :pencil: (RUMM-41): Force line wrapping at 80 characters in md files --- CONTRIBUTING.md | 77 ++++++++++++++++++++++++++++++++----------------- README.md | 26 ++++++++++------- 2 files changed, 66 insertions(+), 37 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f5be653d48..7415c2ec17 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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; @@ -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 @@ -98,7 +119,6 @@ class Foo :Observable(), Runnable { override fun run() {} // endregion - // region Internal @@ -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. diff --git a/README.md b/README.md index ce3e2c0918..b20cc5a427 100644 --- a/README.md +++ b/README.md @@ -2,8 +2,6 @@ > A client-side Android library to interact with Datadog. - - ## Getting Started ## Gradle Dependency @@ -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() { @@ -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)