Updates to Coding Guide

As we go through reviews, some coding patterns appears which are documented in https://github.com/theia-ide/theia/wiki/Coding-Guidelines. Each PR should be reviewed on conformance to it. This channel is to announce updates to rules.

[original thread by Anton Kosyakov]

I’ve added following recently:

I’ve removed Add architectural types to the file name separated by a dot. (e.g. file-navigator.plugin.ts). We’ve never used it. We always use - instead of . in such cases. I think we can just stick to it.

Where should we add things like in order to get human-readable path usesLabelProvider.getLongName</code>? in coding guidelines as well? What would be the good name for such rules?

I’m not sure, maybe best practices?

React: Do not bind functions in event handlers. https://github.com/theia-ide/theia/wiki/Coding-Guidelines#no-bind-fn-in-event-handlers

Any feedback on missing details is welcomed.

Names: unique context keys. https://github.com/theia-ide/theia/wiki/Coding-Guidelines#unique-context-keys

Added example to whole words naming: https://github.com/theia-ide/theia/wiki/Coding-Guidelines#whole-words-names

[Josh Bradley]

What about how modules should be required? Relevant issue here and here. It could affect whether or not a Theia bundled exec can be created.

@jgbradley1 Do you have recommendations? Maybe there are some existing rules adopted by other projects.

Thinking abou it we should add rules how to properly fork Node.js processes that they work in Electron as well.

URI/Path guidelines: https://github.com/theia-ide/theia/wiki/Coding-Guidelines#uripath

Thank your for putting this together, @anton-kosyakov!
Regarding to this rule, I think it should be FileUri.fsPath instead of File.getFsPath. Thoughts?

@kittaakos please update, i’m just trying to document our implicit rules, anyone is welcomed to improve them


It is not really a coding guideline but I was wondering if we should attempt to enforce better commit titles and mandatory messages. The idea is that at any point in time I can look at the git history of a repo, understand a commit more easily and what problem it attempts to solve. At the moment we have many old and new commits which are not descriptive enough. Having this process documented makes it a lot easier during code reviews to refer to it and it’d be a regular and standard part of the review process.

Maybe including it in the file CONTRIBUTING.md is more appropriate?