Skip to content

Latest commit

 

History

History
71 lines (50 loc) · 4.64 KB

CONTRIBUTING.md

File metadata and controls

71 lines (50 loc) · 4.64 KB
Raw

Contributing guideline

We have been receiving a lot of contributions from F# community and we love it. Visual F# Power Tools welcomes your contributions. The purpose of this guideline is to help us work together in an easy and productive way.

Using the issue tracker

  • Bugs - You welcome to fix them. We would love to receive pull requests for bug fixing.
  • Features - It is a good idea to discuss on the issue tracker first if you would like to implement new features.
  • up-for-grabs tag - This tag labels self-contained issues which can be solved without understanding too many details of the code base. They are available for newcomers to take. When someone agrees to help with an up-for-grab issue, we will mark it as taken to avoid duplication of effort.

Discussing features

Requests from F# community will be the source of our upcoming features. You can suggest new features at our user voice system. Please vote for your favourite features in user voice; it will help us prioritize our work better. If you would like to contribute by implementing a new feature, please open a new issue for discussions. If there is already a pull request for the feature, please jump in and discuss; it will help us stabilize the implementation faster.

New to Visual Studio Extensibility (VSX)?

Don't be scared away. We all have been new to VSX. Here are a few resources to get started with VSX:

How is the code base organized?

The code base is structured as follows:

  • FSharpVSPowerTools.Core project consists of IDE-agnostic features that might be reused in other IDEs and editors.
  • FSharpVSPowerTools.Logic project contains most of VS-dependent operations that are required to implement our features.
  • FSharpVSPowerTools is the entry-point project which registers the package, create MEF components and get user configurations via options dialogs.

When you hit F5 (Debug --> Start Debugging) on FSharpVSPowerTools project, an Experimental VS Instance will be opened with the extension being installed. You can set breakpoints in any part of the code to debug or check View --> Output window for debugging logs. This article explains fairly well how Experimental Instance should be used in debugging Visual Studio extensions.

NUnit is used for unit testing. If you modify FSharpVSPowerTools.Core project, please consider to add unit tests to FSharpVSPowerTools.Core.Tests project. FSharpVSPowerTools.Tests project consists of integration tests by mocking VS shells. We use a FAKE script to build the solution, run tests and create user guides. If you implement/modify features, please adjust documentation in content folder. Documentation can be generated by running build.cmd GenerateDocs from command line.

Code Styles

When you consider to contribute, please follow the following coding conventions:

  • Use four spaces for indentation
  • Use camelCase for module functions and PascalCase for type members.
  • When you refer to class instances, use x in a member if you need to refer to that instance; otherwise, please use __ if the class instance isn't used anywhere else. If you reference to the instances in constructors, we generally recommend to use as self pattern.
  • We turn on unused-variable warnings by default, please remove all unused identifiers before sending pull requests. When suppressing unused variables, you could use _ prefix to give them mnemonic names.
  • Use uppercase identifiers for type parameters e.g. 'T, 'U, etc.

If you're in doubt, please follow the common style that has been used in the code base. We recommend these two sources for F# formatting conventions and coding styles:

That's it for now. We look forward to your contributions.