Repository navigation
Provide an official set of Coding Guidelines #878
Description
Hi,
There is an agreeable set of guidlines, apparently for TypeScript internal use. This can be published as an official guideline for general use, with a few modifications (by removing the ones that reference TypeScript internals).
(The only quibble I have is with "Use PascalCase for enum values" and "Use double quotes for strings".)
An official standard will be very useful for settling arguments within organisations.
Thanks!
Activity
FedericoZanin commentedon Dec 18, 2014
An Official set of Coding Guidelines will be very useful.
vvakame commentedon Dec 19, 2014
👍
johnnyreilly commentedon Dec 19, 2014
👍 - I can live with less arguments
zpdDG4gta8XKpMCd commentedon Apr 22, 2016
related #6168
RyanCavanaugh commentedon May 9, 2016
Not sure why it took us 20 months to say this, but in general we're not interested in deciding stylistic things for people. Saying that there's One Approved Style for TS goes against our philosophy that we're here to provide types for JS regardless of how you're writing it (within reasonable parameters, of course 😉).
NoelAbrahams commentedon May 10, 2016
Doesn't make any sense at all. A set of guidelines is not really about deciding anything for people - unless people explicitly wish that it should.
kitsonk commentedon May 10, 2016
There is a big difference between a well informed member of the TypeScript community at large promoting certain stylistic patterns, versus the producers of the language promoting those patterns, because they become "standards" and lead to lots of unintended consequences.
It is proper for the team to be pedantic about the coding style of the TypeScript compiler, but outside that, I agree with team, best for them to stay out of that business.
If parts of the wider community want to be strongly opinionated about the stylistic approach, we have tools like tslint which allow us to enforce those rules. Some people have shared their internal style guidelines, Basarat Ali Syed (@basarat) as his TypeScript Deep Dive guidelines and some projects, like our Dojo 2 have their project's guidelines.
zpdDG4gta8XKpMCd commentedon May 10, 2016
out of curiosity, given everything said above,m how come coding standard exist for C#?
https://msdn.microsoft.com/en-us/library/ff926074.aspx
kitsonk commentedon May 10, 2016
But there are none for PHP, but there are for Rust, but there aren't for ECMAScript. Just because someone else does or doesn't do something does invalidate the logic. So why do you disagree with what Ryan and I said. You feel it is incumbent upon the TypeScript team to dictate to you how to stylistically approach TypeScript?
zpdDG4gta8XKpMCd commentedon May 10, 2016
Where did I say that I disagree? If you read closely I just asked a humble question: It was decided for some languages that it makes sense to establish a official coding convention, whereas for TypeScript it is believed that there is no such necessity. Why is that? [End of a humble question]
Not sure what you mean by dictating. Now no one is in power to dictate me how to write my code. So the official standard is a good faith recommendation at most and a starting point for those who got lost. It doesn't hurt to have it because it might help people in need. Big boys are welcome to go and do whatever they please.
NoelAbrahams commentedon May 10, 2016
Kitson Kelly (@kitsonk),
Official coding guides are invaluable in large organisations where is a constant flux in terms of employees. For example, Joe Bloggs joins from Organisation B where they have a nasty practice of prefixing private methods with underscore then promptly starts converting every private method they come across in the new organisation. In this environment it's helpful to be able to point to something official. In fact, in all probability, Joe Bloggs would have learnt that this practice is discouraged in the TypeScript world in the first place, because of the official standard.
mhegazy commentedon May 10, 2016
We are not saying coding guidelines are not useful, they are, and you should have one for your organization. the TypeScript team follows a set of guidelines as described in https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines, and as enforced in linter rules https://github.com/Microsoft/TypeScript/blob/master/tslint.json. You are welcome to follow these guidelines in whole, or modify them to fit your needs. you are more than welcome to start a set of community driven guidelines, and share them here as well (e.g. some MS users have developed https://github.com/Microsoft/tslint-microsoft-contrib).
All what we are saying is we do not want to be prescriptive about what is a good TS code patterns and what is not.
The rational here is TS is JS. JS developers already have their coding standards, and guidelines; we believe these are a good place to start, adapt them to fit the TS language (e.g. do not use
_instead useprotected) and you are good to go.TS is trying to model patterns already in use in the JS world and is not a completely new language that can afford to impose strict guidelines like C# for instance.