<p>In Python, everybody is supposed to follow <a href="https://peps.python.org/pep-0008/" rel="nofollow noreferrer">PEP 8</a> when writing code. In Java, there are various competing style guides, the most popular of which being <a href="https://google.github.io/styleguide/javaguide.html" rel="nofollow noreferrer">Google's</a>, but there's no centralized, universally accepted set of conventions.</p>
<p>As a language designer, why might or might not I write a style guide for my language and attempt to get developers to comply?</p>

<style><language-usage><conventions>
When should languages have a manual of style?
<p>More of a comparison then a strict guideline, but:</p>
<h2>Advantages:</h2>
<ul>
<li>All code written in your language looks the same</li>
<li>You don't need an official formatter - users can make their own, and just follow the standard</li>
<li>If you allow the guide to develop somewhat organically, it will serve as a good introduction to what code in your language feels like</li>
<li>You get to make the code style something you enjoy ;)</li>
</ul>
<h2>Disadvantages:</h2>
<ul>
<li>Requires a fair amount of effort to cover every edge case</li>
<li>Less customisability</li>
<li>Users who don't like the style are forced to use it</li>
<li>Not having an official formatter could end in a clippy-like situation, where you end up just absorbing one anyway because it's easier/faster/a really good tool/etc</li>
</ul>

CC BY-SA 4.0
2023-05-17T05:07:41.680Z
2023-05-17T05:07:41.680Z
blueberry
CC BY-SA 4.0
2023-05-17T06:37:59.680Z
Style guides do not need to cover every edge case, and in my opinion should not. In weird situations the style should just be the programmers call.
mousetail 'he-him'
<p>I think style guides are generally a good thing, since they can preclude endless arguments over objectively unimportant things, which people nonetheless behave as if they are very important. Particularly if you're the kind of person who likes writing style guides then please don't let anyone stop you!</p>
<p>That said, I'll play devil's advocate here and argue that most languages do not need style guides ─ not because they have too few users for it to matter (as true as that may be), but because most languages have a syntax based on other popular languages, which there are already widely agreed upon style conventions for. For example, it's generally agreed in almost all languages that</p>
<ul>
<li>Blocks should be indented according to their nesting level, even when this isn't syntactically required,</li>
<li>Binary operators should have spaces between the operands and the operator,</li>
<li>Names should range from clear and descriptive (for top-level or public declarations) to concise (for local variables) as appropriate, and follow the same casing conventions as the standard library,</li>
<li>Comments should usually appear on separate lines, before the lines they are describing.</li>
</ul>
<p>Among other things. Unless your language is really out there in terms of its syntax, any style guide you write will probably not say much that isn't already written in the style guides of the languages whose syntax you borrowed from. So yes, keep to a consistent style when you are writing the standard library and tutorial examples, but there is probably not much need to codify that style in a formal document until your language starts getting used by engineers at Google and Microsoft.</p>

CC BY-SA 4.0
2023-05-17T06:56:46.403Z
2023-05-17T06:56:46.403Z
kaya3
<h2>You need a style guide for the standard library and examples anyways</h2>
<p>Irrespective of user code any language needs many code samples for the documentation, maybe a standard library, maybe you'll write some extra packages to kickstart the ecosystem. You'll want a standard style for those for the same reason you want a standard style in any other single project.</p>
<p>If you have a style guide anyway, you might as well publish it. The community can decide to adopt your style guide or invent a different one. There are many rules in PEP 8 that the community doesn't really follow.</p>
<p>In fact, that is what PEP 8 is, it was originally intended for just for python's standard library, complemented by PEP 7 which is a C style guide for the C parts.</p>

CC BY-SA 4.0
2023-05-17T05:44:20.883Z
2023-05-17T05:44:20.883Z
mousetail 'he-him'
CC BY-SA 4.0
2023-07-01T09:02:57.970Z
I really like the uncompromising approach of the Go community: there is a formatter distributed as part of the standard distribution, this formatter has no configuration file, no options, no flags, no parameters – there is one and only one way to format Go code, period. The Go compiler and the Go standard library only accept contributions that have been formatted with this formatter. As a result, every Go programmer runs the formatter on their code every time they save, commit, or push. This, in turn, has enabled the Go designers to make incompatible changes to Go, by adding a rewrite …
Jörg W Mittag
CC BY-SA 4.0
2023-07-01T09:03:28.603Z
… to the formatter. Since everybody constantly runs the formatter, their code will automatically be rewritten from the old to the new syntax at some point. Pretty cool if you think about it.
Jörg W Mittag
CC BY-SA 4.0
2023-07-01T09:58:17.807Z
@JörgWMittag I do think such a approach would be wildly unpopular in most languages. Nicely formatted code is important but so is keeping your community happy. Also upgrading the language to a new version should not be the responsibility of a formatter
mousetail 'he-him'
# When should languages have a manual of style?
Posted by: username_0 on 2023-05-17
In Python, everybody is supposed to follow [PEP 8](https://peps.python.org/pep-0008/) when writing code. In Java, there are various competing style guides, the most popular of which being [Google's](https://google.github.io/styleguide/javaguide.html), but there's no centralized, universally accepted set of conventions.

As a language designer, why might or might not I write a style guide for my language and attempt to get developers to comply?
**Tags:** style language-usage conventions
---
## 3 answers
### Answer by username_2 on 2023-05-17. Score: 4 | Accepted answer
## You need a style guide for the standard library and examples anyways

Irrespective of user code any language needs many code samples for the documentation, maybe a standard library, maybe you'll write some extra packages to kickstart the ecosystem. You'll want a standard style for those for the same reason you want a standard style in any other single project.

If you have a style guide anyway, you might as well publish it. The community can decide to adopt your style guide or invent a different one. There are many rules in PEP 8 that the community doesn't really follow.

In fact, that is what PEP 8 is, it was originally intended for just for python's standard library, complemented by PEP 7 which is a C style guide for the C parts.
> **Comments:**
> **username_4** (2023-07-01): I really like the uncompromising approach of the Go community: there is a formatter distributed as part of the standard distribution, this formatter has no configuration file, no options, no flags, no parameters – there is one and only one way to format Go code, period. The Go compiler and the Go standard library only accept contributions that have been formatted with this formatter. As a result, every Go programmer runs the formatter on their code every time they save, commit, or push. This, in turn, has enabled the Go designers to make incompatible changes to Go, by adding a rewrite …  
> **username_4** (2023-07-01): … to the formatter. Since everybody constantly runs the formatter, their code will automatically be rewritten from the old to the new syntax at some point. Pretty cool if you think about it.  
> **username_2** (2023-07-01): @JörgWMittag I do think such a approach would be wildly unpopular in most languages. Nicely formatted code is important but so is keeping your community happy. Also upgrading the language to a new version should not be the responsibility of a formatter  
---
### Answer by username_3 on 2023-05-17. Score: 3
I think style guides are generally a good thing, since they can preclude endless arguments over objectively unimportant things, which people nonetheless behave as if they are very important. Particularly if you're the kind of person who likes writing style guides then please don't let anyone stop you!

That said, I'll play devil's advocate here and argue that most languages do not need style guides ─ not because they have too few users for it to matter (as true as that may be), but because most languages have a syntax based on other popular languages, which there are already widely agreed upon style conventions for. For example, it's generally agreed in almost all languages that

* Blocks should be indented according to their nesting level, even when this isn't syntactically required,
* Binary operators should have spaces between the operands and the operator,
* Names should range from clear and descriptive (for top-level or public declarations) to concise (for local variables) as appropriate, and follow the same casing conventions as the standard library,
* Comments should usually appear on separate lines, before the lines they are describing.

Among other things. Unless your language is really out there in terms of its syntax, any style guide you write will probably not say much that isn't already written in the style guides of the languages whose syntax you borrowed from. So yes, keep to a consistent style when you are writing the standard library and tutorial examples, but there is probably not much need to codify that style in a formal document until your language starts getting used by engineers at Google and Microsoft.
---
### Answer by username_1 on 2023-05-17. Score: 1
More of a comparison then a strict guideline, but:

## Advantages:

* All code written in your language looks the same
* You don't need an official formatter - users can make their own, and just follow the standard
* If you allow the guide to develop somewhat organically, it will serve as a good introduction to what code in your language feels like
* You get to make the code style something you enjoy ;)

## Disadvantages:

* Requires a fair amount of effort to cover every edge case
* Less customisability
* Users who don't like the style are forced to use it
* Not having an official formatter could end in a clippy-like situation, where you end up just absorbing one anyway because it's easier/faster/a really good tool/etc
> **Comments:**
> **username_2** (2023-05-17): Style guides do not need to cover every edge case, and in my opinion should not. In weird situations the style should just be the programmers call.  
---
