Provide an official set of Coding Guidelines

[NoelAbrahams]

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!

[FedericoZanin]

An Official set of Coding Guidelines will be very useful.

[vvakame]

👍

[johnnyreilly]

👍 - I can live with less arguments

[zpdDG4gta8XKpMCd]

related #6168

[RyanCavanaugh]

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]

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]

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.

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 as his TypeScript Deep Dive guidelines and some projects, like our Dojo 2 have their project's guidelines.

[zpdDG4gta8XKpMCd]

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]

out of curiosity, given everything said above,m how come coding standard exist for C#?

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]

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]

@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]

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 use protected) 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.