Settle on linebreak style #192
Comments
|
+1 for your proposal |
|
I would personally vote to have a limit because otherwise some lines will have >300 chars (or even more). |
|
Applying review suggestions is a good point: since github doesn't let you suggest multiline hunks this means the OP has to break out the editor for even simple changes. I'm happy with 300+ char lines since I can soft wrap them in my own editor. |
|
I suggest that we do one of these:
Either works fine for diffing in Github. 1 is more manual work, 2 requires your editor to support soft wrapping. My vote goes to 2, but I am open to doing 1 if majority wants that. I would refrain from hard breaking at large column numbers precisely because of what @c24t said above. |
|
I also vote for having a limit - either 80 or 100 should be fine (and friendlier). |
|
If I can chime in, from my perspective, hard limit at 80 or 100 will be the best for reasons like:
|
|
Strong support for soft breaks:
|
iredelmeier
added
the
needs discussion
|
I think that soft breaks would be best, as, contrary to source code files, soft-wrapping works very well for (plain english) text files. Regarding the pin-pointing things in lines issue: You could add a hard break after every sentence, or after every clause (wherever you think it makes sense semantically). |
|
From the spec SIG call today: let's use soft breaks, revisit if we decide that this was a mistake. |
* error handling proposal * added self-monitoring * Reword principles * Reword guidance * Reword diagnostics * Reword exceptions * Add note on logs, callbacks * Formatting * formatting and a mention of ToString * dynamic languages * returning noops, not nulls * Reformat for #192 * Update specification/error-handling.md Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
* error handling proposal * added self-monitoring * Reword principles * Reword guidance * Reword diagnostics * Reword exceptions * Add note on logs, callbacks * Formatting * formatting and a mention of ToString * dynamic languages * returning noops, not nulls * Reformat for open-telemetry#192 * Update specification/error-handling.md Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples. This was split from OTEP open-telemetry#192, which became too comprehensive.
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples. This was split from OTEP open-telemetry#192, which became too comprehensive.
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples. This was split from OTEP open-telemetry#192, which became too comprehensive.
* error handling proposal * added self-monitoring * Reword principles * Reword guidance * Reword diagnostics * Reword exceptions * Add note on logs, callbacks * Formatting * formatting and a mention of ToString * dynamic languages * returning noops, not nulls * Reformat for open-telemetry#192 * Update specification/error-handling.md Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples. This was split from OTEP open-telemetry#192, which became too comprehensive.
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples. This was split from OTEP open-telemetry#192, which became too comprehensive.
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples. This was split from OTEP open-telemetry#192, which became too comprehensive.
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples. This was split from OTEP #192, which became too comprehensive.
Motivated by #190 (comment).
We don't have a consistent style for wrapping long lines of prose. It may not be worth the trouble to enforce a specific style, but we should either pick one now or agree not to enforce this going forward.
Of the files in the spec that have a mostly consistent style:
Hard breaks at 80 chars: 6 files, generally @SergeyKanzhelev and @bogdandrutu
Hard breaks at > 80 chars: 2 files, generally @songy23
Break at end of paragraph: 3 files, generally @tigrannajaryan, @mayurkale22, and @iredelmeier
This is almost entirely a matter of personal taste, so if anyone has an opinion I'd like to hear it. I'd prefer to put a single break at the end of each sentence and blank lines in between paragraphs because this tends to produce nice diffs.
The text was updated successfully, but these errors were encountered: