Skip to content

Commit 056ab25

Browse files
authored
Remove TODO about non-inline block comments. (#1400)
The TODO questions whether we should make a distinction between C-style block comments that have newlines around them in the original source or not. If we don't, then the formatter would turn code like: ```dart main() { /* entireBody(); commentedOut(); forSomeReason(); */ } ``` Into: ```dart main() {/* entireBody(); commentedOut(); forSomeReason(); */} ``` I did a little scraping of a corpus, and there are quite a few block comments like this in the wild, and I think it looks better to keep them on their own lines if the input code has a newline before or after the comment. Also, the implementation complexity of distinguishing inline block comments and non-inline ones is trivial. Removing support for it would change like three lines of code. So I think it's best to just keep supporting the distinction because it leads to better output, is consistent with the current formatter, and doesn't add much complexity.
1 parent 94abf95 commit 056ab25

File tree

1 file changed

+0
-4
lines changed

1 file changed

+0
-4
lines changed

lib/src/front_end/comment_writer.dart

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -113,10 +113,6 @@ class CommentWriter {
113113
} else if (comment.type == TokenType.SINGLE_LINE_COMMENT) {
114114
type = CommentType.line;
115115
} else if (commentLine == previousLine || commentLine == tokenLine) {
116-
// TODO(tall): I'm not sure if it makes sense to distinguish block
117-
// comments with newlines around them from other block comments in the
118-
// new Piece representation. Consider merging CommentType.inlineBlock
119-
// and CommentType.block into a single type.
120116
type = CommentType.inlineBlock;
121117
} else {
122118
type = CommentType.block;

0 commit comments

Comments
 (0)