Skip to main content
CommentSense is configured through .editorconfig files in your project. This allows you to customize the analyzer’s behavior at the solution, project, or even file level.

​
How Configuration Works

CommentSense uses the standard .editorconfig format to read configuration options. All CommentSense options are prefixed with comment_sense. and should be placed under the [*.cs] section to apply to all C# files.

​
Basic .editorconfig Structure

root = true

[*.cs]
# CommentSense configuration options go here
comment_sense.visibility_level = protected
comment_sense.require_ending_punctuation = true
The .editorconfig file should be placed in your project root or solution directory. Options cascade from parent directories, with more specific (closer) files taking precedence.

​
Configuration Scope

You can configure CommentSense at different levels:
  • Solution-level: Place .editorconfig in your solution root
  • Project-level: Place .editorconfig in individual project directories
  • File-level: Use glob patterns to target specific files or directories

​
Example: Different Rules for Different Directories

root = true

# Default for all C# files
[*.cs]
comment_sense.visibility_level = protected
comment_sense.require_ending_punctuation = true

# Stricter rules for public API
[src/PublicApi/**/*.cs]
comment_sense.visibility_level = public
comment_sense.min_summary_length = 20
comment_sense.require_capitalization = true

# Relaxed rules for internal utilities
[src/Internal/**/*.cs]
comment_sense.visibility_level = internal
comment_sense.exclude_constants = true

​
Common Configuration Patterns

​
Minimal Configuration (Defaults)

By default, CommentSense uses sensible defaults. You don’t need any configuration to get started: 
[*.cs]
# These are the default values - no configuration needed
# comment_sense.visibility_level = protected
# comment_sense.allow_implicit_inheritdoc = true
# comment_sense.require_ending_punctuation = false
# comment_sense.require_capitalization = false

​
Strict Documentation Standards

For projects with high documentation standards: 
[*.cs]
comment_sense.visibility_level = public
comment_sense.min_summary_length = 15
comment_sense.require_ending_punctuation = true
comment_sense.require_capitalization = true
comment_sense.similarity_threshold = 0.8
comment_sense.allow_implicit_inheritdoc = false
comment_sense.low_quality_terms = TODO, TBD, FixMe, None, N/A

​
Relaxed for Internal Code

For internal projects or utilities: 
[*.cs]
comment_sense.visibility_level = internal
comment_sense.exclude_constants = true
comment_sense.exclude_enums = true
comment_sense.require_ending_punctuation = false

​
Configuration Options Reference

CommentSense provides configuration options in the following categories:

Visibility Levels

Control which members are analyzed based on their accessibility

Quality Checks

Configure low quality detection, langwords, ghost references, and tag ordering

Exception Documentation

Configure which exceptions to document and exception scanning behavior

Advanced Options

Conditional suppression, constant/enum exclusions, and implicit inheritdoc

​
Prerequisites

CommentSense requires XML documentation generation to be enabled in your project. Add this to your .csproj file:
<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>
Without this setting, CommentSense will report diagnostic CSENSE000 and will not analyze your code.

​
Validation and Testing

After configuring CommentSense:
  1. Rebuild your project to ensure the analyzer picks up the new settings
  2. Check the Error List in Visual Studio to see active diagnostics
  3. Test with sample code to verify the configuration behaves as expected
Configuration changes are applied immediately when the .editorconfig file is saved, but you may need to reload files or rebuild to see all changes reflected in the IDE.

​
Next Steps

1

Set Visibility Level

Configure which members should be analyzed based on visibility levels
2

Enable Quality Checks

Set up quality checks for documentation standards
3

Configure Exceptions

Customize exception documentation requirements
4

Fine-tune Advanced Options

Explore advanced configuration for edge cases

Build docs developers (and LLMs) love

Get started for freeTalk to us