4 ms·

What about Go? It seems like their approach is that if they define the style guide and build it into tooling, your code style (for Go) can only be the 'approved

What about Go? It seems like their approach is that if they define the style guide and build it into tooling, your code style (for Go) can only be the 'approved' style. Or, put another way: People only have code styles because languages leave ambiguity. By removing that ambiguity you force your user-base to be consistent therefore increasing communication and productivity. I tend to agree. It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. Granted it can be tough if you use three different languages with three different sets of rules.

ChrisSD 7y ago
Rust has grappled with the issue of how far to push styling rules. E.g. from 2016: https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227561639 https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227... I think it's worth reading more of that thread for some pros and cons of being very strict with styling rules. Note that being too strict can lead to code being less readable in specific edge cases. This may or may not be considered a fair trade off.
- Reelin 7y ago
  To summarize the linked post (which I completely agree with), just provide officially recommended sane defaults and then get out of the user's way. In my view, that's how nearly all software ought to be written.
Reelin 7y ago
It's a fundamentally flawed approach in my opinion; viewing the users of a language as a single unified user base is a mistake. Various projects and groups will inevitably have vastly different use cases, and thus needs and considerations. For example, I liberally mix C, C++, D, and occasionally other languages within a single code base on my personal projects. For sanity, I choose to observe my own consistent style across all languages when doing so. This obviously doesn't match common practice for any of the languages in question, but thankfully none of them attempt to impose the opinions of their designers on me. I view languages being concerned with code formatting as a form of scope creep. A language should facilitate good code and communication by thoughtfully designing the syntax and providing useful constructs to the programmer. That's already an incredibly difficult problem - trying to tackle additional interpersonal or organizational issues is far too much, can't possibly accommodate everyone, and is bound to have unexpected negative consequences. Put another way, core infrastructure should nearly always be as unopinionated as possible. Stick to as narrow a design goal as is reasonably possible and execute on it as well as possible. For a language, that means faithfully translating whatever I throw at it into machine code unless there is a legitimate technical barrier in the way of doing so. > It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. If this is happening it's indicative of an organizational or managerial problem. Any given project should have a clearly defined (and consistently enforced) code style, ranging from "use gofmt" to "follow PEP 8" to "adhere to our internal style guide".

ChrisSD 7y ago

Rust has grappled with the issue of how far to push styling rules. E.g. from 2016: https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227561639 https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227... I think it's worth reading more of that thread for some pros and cons of being very strict with styling rules. Note that being too strict can lead to code being less readable in specific edge cases. This may or may not be considered a fair trade off.

Reelin 7y ago
To summarize the linked post (which I completely agree with), just provide officially recommended sane defaults and then get out of the user's way. In my view, that's how nearly all software ought to be written.

Reelin 7y ago

It's a fundamentally flawed approach in my opinion; viewing the users of a language as a single unified user base is a mistake. Various projects and groups will inevitably have vastly different use cases, and thus needs and considerations. For example, I liberally mix C, C++, D, and occasionally other languages within a single code base on my personal projects. For sanity, I choose to observe my own consistent style across all languages when doing so. This obviously doesn't match common practice for any of the languages in question, but thankfully none of them attempt to impose the opinions of their designers on me. I view languages being concerned with code formatting as a form of scope creep. A language should facilitate good code and communication by thoughtfully designing the syntax and providing useful constructs to the programmer. That's already an incredibly difficult problem - trying to tackle additional interpersonal or organizational issues is far too much, can't possibly accommodate everyone, and is bound to have unexpected negative consequences. Put another way, core infrastructure should nearly always be as unopinionated as possible. Stick to as narrow a design goal as is reasonably possible and execute on it as well as possible. For a language, that means faithfully translating whatever I throw at it into machine code unless there is a legitimate technical barrier in the way of doing so. > It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. If this is happening it's indicative of an organizational or managerial problem. Any given project should have a clearly defined (and consistently enforced) code style, ranging from "use gofmt" to "follow PEP 8" to "adhere to our internal style guide".