Conversation
| @@ -1,14 +1,16 @@ | |||
| | |||
There was a problem hiding this comment.
Лучше не включать в МР, т.к. изменения были сгененрированы IDE автоматически и не имеют прямого отношения к МР
cs/Markdown/Pipeline.cs
Outdated
There was a problem hiding this comment.
На данный момент нет необходимости выносить эту логику в отдельный класс, давай перенесем ее в Md.Render()
cs/Markdown/Parsing/InlineParser.cs
Outdated
There was a problem hiding this comment.
Экранирование должно обрабатываться до парсинга тегов
cs/Markdown/Parsing/InlineParser.cs
Outdated
There was a problem hiding this comment.
Разбиение парсера на 5 классов избыточно, каждый из предложенных классов будет содержать 1-2 метода что усложнит архитектуру без реальной поьзы, классы не будут являться самостоятельными сущностями, а будут лишь шагами алгоритма
Отдельные классы стоило бы выделить в случае переиспользования логики или разных "профилей" парсера (например, с конфигурируемыми настройками), в этом кейсе такой необходимости нет
There was a problem hiding this comment.
Возможно для упрощения логики парсера стоит вынести отдельный этап предварительной обработки текста которая подготавливает его к основному парсингу, заменяя "мешающие" элементы на временные маркеры
cs/Markdown/Blocks/IBlock.cs
Outdated
There was a problem hiding this comment.
Нет необходимости в наследниках исходя из текущих требований, лучше добавить поле BlockType. Разница HeadingBlock и ParagraphBlock только в рендеринге, хранятся и обрабатываются данные одинаково. Наследники понадобились бы, например, в случае разных структур данных
cs/Markdown/Blocks/IBlock.cs
Outdated
There was a problem hiding this comment.
Какие преимущества перед сеттером? Точно ли нужен этот метод?
There was a problem hiding this comment.
Какие преимущества перед сеттером? Точно ли нужен этот метод?
Посидел, подумал и не нашел ни одной причины, по которой бы использование SetInlines было бы лучше использования дефолтного сеттера
Мне кажется под заданные требования будет достаточно просто сеттера. В итоговой реализации поправлю этот момент
|
Заметила что для некоторых компонентов выделены отдельные папки, содержащие по одному файлу. Предлагаю убрать, т.к. они избыточны и усложняют навигацию |
RomanGleyzer
force-pushed
the
master
branch
4 times, most recently
from
29a056e to
39c6c27
Compare
RomanGleyzer
force-pushed
the
master
branch
2 times, most recently
from
d0d2003 to
0b0c12d
Compare
cs/Markdown/Md.cs
Outdated
There was a problem hiding this comment.
Давай передавать зависимости в конструктор, а не в метод. Класс должен скрывать детали реализации. Передавать в метод не стоит, т.к. не получится инжектировать зависимости через di + это нарушает инкасуляцию: любой внешний код вызывающий этот метод будет знать какие зависимости передавать, как их конфигурировать и т.д.
cs/Markdown/Inlines/InlineSyntax.cs
Outdated
cs/MarkdownTests/MarkdownTests.sln
Outdated
There was a problem hiding this comment.
не нужно тесты выделять в солюшн, проекта достаточно
There was a problem hiding this comment.
в МР не нужно включать
Удалил эти файлы
There was a problem hiding this comment.
не нужно тесты выделять в солюшн, проекта достаточно
Отказался от .sln. Сейчас в папке проекта нет такого решения
| } | ||
| } | ||
| return sb.ToString(); | ||
| } |
There was a problem hiding this comment.
Метод нечитабельный, нужно разбить/сделать компактнее
cs/Markdown/Inlines/InlineParser.cs
Outdated
cs/Markdown/HtmlRenderer.cs
Outdated
There was a problem hiding this comment.
Вынесем вспомогательные методы для читабельности? Метод получился большой и есть блоки которые напрашиваются в отдельный метод
cs/Markdown/HtmlRenderer.cs
Outdated
cs/Markdown/HtmlRenderer.cs
Outdated
There was a problem hiding this comment.
В случае пусто строки ничего не добавляет, но вызывает метод. Лучше сделать проверку на пустую строку
There was a problem hiding this comment.
давай уберем эти вспомогательные методы, они не сокращают кол-во строк в тесте, зато сокращают читабельность: вместо того чтобы открыть тест и посмотреть что там происходит, приходится проваливаться в эти методы и смотреть что там внутри
There was a problem hiding this comment.
Нужно разделить на 3 отдельных теста
There was a problem hiding this comment.
здесь что проверяется?
хотел проверить, что строки, содержащие html теги, не меняются и выводятся как обычный текст в абзаце
There was a problem hiding this comment.
здесь что проверяется?
Постарался подобрать более читаемое название. Остановился на варианте "Render_TextWithHtmlTags_KeepsHtmlTags"
There was a problem hiding this comment.
очень запутанные названия, давай упростим и если требуется добавим описания к тестам
кстати, почему parseandrender когда тестируется метод render?
There was a problem hiding this comment.
нужно разделить на 3 теста (возможно тесткейсы)
There was a problem hiding this comment.
эти 3 логичнее объединить в тест с тесткейсами
| "Но <em>внутри __одинарного__ не</em> работает. Конец\\\\</p>"; | ||
|
|
||
| Normalize(RenderHtml(Paragraph)).Should().Be(expected); | ||
| } |
There was a problem hiding this comment.
Можно добавить тесты на граничные случаи (например, пустые строки/только пробелы между разделителями/максимальная вложенность/unicode символы и др)
There was a problem hiding this comment.
почему константа? почему с большой буквы? отличается от других тестов
There was a problem hiding this comment.
антипаттерн, если тест упадет то не понятно почему именно упал и что сломалось, нарушен принцип 1 тест = 1 сценарий
cs/MarkdownTests/PerformanceTests.cs
Outdated
There was a problem hiding this comment.
Один фиксированный паттерн, не отражает реальное использование. Для более реальных тестовых данных можно сделать массив паттернов и рандомно генерировать из них текст
There was a problem hiding this comment.
+ можно добавить несколько итераций для усреднения результатов теста
| namespace MarkdownTests; | ||
|
|
||
| [TestFixture] | ||
| public class PerformanceTests |
There was a problem hiding this comment.
Можно добавить тесты на конкретные случаи, например, очень большая вложенность
2 participants
@masssha1308
upd:
Предполагаемый алгоритм обработки текста: