Shorten code files about markdownsharp

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Markdown.cs has always been a single file by design; not sure why arbitrarily
breaking it into other files would help.

However, if you're referring to the test project, I am open to whatever changes 
make
sense there.. I am not very experienced with unit tests.

Original comment by [email protected] on 26 Dec 2009 at 10:12

[GoogleCodeExporter]

Well, I find that maintaining code files of more than ~300 lines to be 
difficult. If I find a good way to split it up 
and post a patch for it, would you at least have a look at it? I'd be happy to 
help with unit testing as well, which 
would be much easier to split up into smaller parts if the code it tests is 
split up as well.

The unit tests should, by namespace, class file and method name, precisely 
describe exactly what they test. If all 
the code they test is lumped together in one file, it's harder to separate the 
tests into logical parts.

Original comment by asbjornu on 26 Dec 2009 at 10:43

[GoogleCodeExporter]

While I agree that code files should be as short as they can be, I think 
markdown
makes the most sense as one file. I have no preference on the unit tests.

What specifically is so difficult about maintaining a file with more than 300 
lines?
Can you provide some examples of where this is a problem? I guess I just don't 
get
it. I don't have any problems working with it; I typically navigate using 
incremental
search.

http://www.codinghorror.com/blog/archives/000432.html

Original comment by [email protected] on 30 Dec 2009 at 7:28

[GoogleCodeExporter]

The problem isn't the search. It's requiring search itself to being able to 
navigate the code. While incremental 
search is fantastic, I find a shorter, narrower entrance to any code to be much 
more intuitive than a 1.000 mile 
wide gate with little direction. If the code is segmented into logical groups, 
I find that it's easier to follow and 
understand. It's not a big issue. I can provide patches for it and you can 
decline them if you want to. I'll have a 
look on unit testing as well when I dive into it.

Original comment by asbjornu on 1 Jan 2010 at 5:41

[GoogleCodeExporter]

One problem with large classes is that if all code is in one class, sometimes 
private 
method access just isn't good enough.  If you have a private method in a large 
class, 
it isn't instantly obvious to the reader whether it's used one time or one 
hundred 
times.  

Here is a patch that demonstrates that to some extent.

If I had a copy of Clean 
Code(http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&s=books&qid=1262375524&sr=8-1) 
handy I 
think I could dig up some more well-worded justifications for this.

Original comment by [email protected] on 1 Jan 2010 at 7:52

Attachments:

• moveIsolatedMethodsToNewClasses.patch

[GoogleCodeExporter]

I appreciate the contribution, but I just don't agree that we need a whole 
*class*
called "Detabber" just to hold a single detab() routine.. and another called
"Outdenter" to hold a single outdent() routine.

Original comment by [email protected] on 4 Jan 2010 at 12:30

[GoogleCodeExporter]

Fair enough.  In my mind "a whole class" is not very much.  Classes are 
lightweight 
things that can be used to limit scope.  A class should be something small and 
easy to 
understand.  

But, I recognize that not everything thinks that way.

I will see if I can find another way to help.  

Original comment by [email protected] on 4 Jan 2010 at 12:40