Split Markdown.cs into several partial class files

[GoogleCodeExporter]

Split Markdown.cs into several partial class files

[GoogleCodeExporter]

+    <Compile Include="Markdown.Anchor.cs" />
+    <Compile Include="Markdown.Block.cs" />
+    <Compile Include="Markdown.Config.cs" />
+    <Compile Include="Markdown.Email.cs" />
+    <Compile Include="Markdown.Image.cs" />
+    <Compile Include="Markdown.Inline.cs" />
+    <Compile Include="Markdown.Tab.cs" />
+    <Compile Include="Markdown.Code.cs" />
+    <Compile Include="Markdown.Header.cs" />
+    <Compile Include="Markdown.Link.cs" />
+    <Compile Include="Markdown.List.cs" />
+    <Compile Include="Markdown.Quote.cs" />

This is a completely untenable patch for me -- every time I update Stack 
Overflow, I
now need to paste in 12-13 files instead of one?

I just don't agree that there's any benefit in breaking it apart, because...

a) the current markdown.cs is, IMHO, not too long; I have no trouble working on 
it

b) everything in markdown.cs relates to Markdown and thematically belongs 
together

c) there's no benefit other than "I just like shorter files" to doing this -- 
no bugs
are fixed, no new features are added. It could also be argued this is a 
negative:
instead of a simple single file, there are now 12 files to keep track of, which
probably have to go in their own folder, which has to be kept track of, etc etc 
etc.

I think you might look at forking the project if you want to rearchitect it so 
radically.

Original comment by [email protected] on 7 Jan 2010 at 9:25

[GoogleCodeExporter]

When you update Stack Overflow, how do you do it? Perhaps the workflow in 
updating 
Stack Overflow can be improved or changed, allowing this refactoring to go 
through 
without adding any overhead to updating SO?

a) It's a matter of taste, of course, but I find that any file that surpass 
somewhere around 500 lines to be too long.

b) Yes, this is why it's in one project. Keeping everything in one file beause 
it 
"thematically belongs together" is imho a stretch, though. It would be no 
problem to 
encapsulate all logic even further than what I have by creating separate 
classes for 
separate concerns (there are almost no cross-file method calls involved), but I 
think partial classes solves the issue well enough.

c) Having shorter code files fixes no bugs, true. The "feature" this 
refactoring 
adds, though, is to make it a lot easier to dig into the correct file when you 
want 
to fix e.g. the anchor logic, plus it makes the project easier to understand 
for 
newcomers.

I'm not interested in forking; duplication of effort is usually a bad idea. I 
hope 
instead that we can find some kind of compromise that solves this issue without 
making it harder for you to work on the project. :)

Original comment by asbjornu on 7 Jan 2010 at 9:38

[GoogleCodeExporter]

I appreciate the input, but we will have to agree to disagree.

I sure would prefer some help on our failing unit test, than this discussion on 
the
color of our bikeshed.. :)

Original comment by [email protected] on 7 Jan 2010 at 9:40

• Changed state: WontFix

[GoogleCodeExporter]

That's okay. You're the king of this castle. :)

Original comment by asbjornu on 7 Jan 2010 at 1:56