Re: Taking a single large .cs file and making many smaller .cs fil

Hi Lucian,
I definitely do not agree with these rules in terms of only having 3
methods per class, seems a small number:
Indeed by refactoring. In an ideal world a class would have no more than 3
methods and about 15 lines of code per method but these are just arguable
guidelines.

However going the other way and saying to put thousands of lines of code in
a class is not good either in my opinion.

Lucian's addendum: "Adding a layer of indirection always creates more
problems than it solves."
If this were true why have any indirection at all, just have one big
monolithic chunk of code - that would then have less problems than a layered
approach - hummm I don't think this is the case in real life.

Am I the only person who prefers larger files (around 4000-5000 lines)
and larger methods (10-200 lines) ?
From the code I have had to look at / modify over the year I would say
definitely not, there are plenty of people writing code with thousands of
lines in a single file and methods that are hundreds of lines long. However
the code in these files from my experience is generally not very Object
Oriented even if written in an OO language, functionality and code is
duplicated and the responsibility of the classes are not clear, since they
have become large monolithic kind of classes. I am not saying this is always
the case but 95% of the time I have seen this.


and it encourages the mindset we're
you're only aware of the small bit of code that you're working on, no
longer so aware of the larger picture. And you can't print out the
code very easily.
I find breaking things down into small pieces makes it more manageable, if
I want to be aware of the larger picture I think it is much clearer to have
smaller bits which you can see fit together in your design doc (i.e. class
diagrams, sequence diagrams and most importantly unit testing which shows how
code should be used), however once you start getting fewer classes and much
larger methods which encompass more functionality it is not as clear what
something is really doing unless you digg into the code, you may call a
single method but it does 50 things, maybe not clear from UML notation.

One of the main matras I follow is "one rule, one place" so if something can
be reused then put it into a method and allow it to be called from multiple
places, if this functionality is being duplicated everywhere then the code is
hard to refactor. Code that is not written like this is unnecessarily large
and difficult to maintain.

It is pretty funny for me this post came up, since the whole of today I have
been digging through some code which has some 6000 plus lines in a file, the
code inside the methods is duplicated in many methods making the intent very
unclear and printing out methods that span 8 to 10 pages just makes them
unreadable to follow on paper.

Mark.
--
http://www.markdawson.org


"Lucian Wischik" wrote:

"Gabriel Lozano-Morán" <abuse@xxxxxxxxxxxxxxx> wrote:
Indeed by refactoring. In an ideal world a class would have no more than 3
methods and about 15 lines of code per method but these are just arguable
guidelines.

Famous saying: "Every problem in computer science can be solved by
adding a layer of indirection."
Lucian's addendum: "Adding a layer of indirection always creates more
problems than it solves."

Am I the only person who prefers larger files (around 4000-5000 lines)
and larger methods (10-200 lines) ?

The way I see it, if there are multiple files then it's harder to keep
track of what each file does, it's harder to do the sort of
refactoring that would involve changing these files -- especially if
they're under source control -- and it encourages the mindset we're
you're only aware of the small bit of code that you're working on, no
longer so aware of the larger picture. And you can't print out the
code very easily. And it's easier for other people to incorporate your
module as source code if it comprises only a small number of source
files.

Finally, if you have one file per class, then there's no longer a good
place to write "architecture/design" comments that span multiple
classes. These comments are the single most important part of
programming, I think.

As for procedures, a lot of procedures just do (say) ten things in a
row, one after the other. And each of those ten things might involve
ten smaller things. You could factor each one out into a separate
procedure, sure. But that creates extra layers of "mental indirection"
-- the person reading your code no longer has such a clear idea of
where the function might be called from, where it fits in, what its
public/private visibility is, and so on. If you leave them all in the
same 100-line procedure then it's clear how they fit in.

If we do as you say and have classes with only very few methods, then
the reader of your code suddenly has a lot of extra mental complexity
to keep track of all the classes. I think it's easier to keep track of
normal methods within a class than it is to keep track of classes and
their using/inheritance/calling/visibility relationships.

I guess I feel that progressively breaking the problem down into
smaller pieces is useful only inasmuch as its needed for human
comprehension. Once we get beyond that point, and we start breaking it
down smaller we're actually hindering comprehension.

--
Lucian

.

Relevant Pages

  • Re: Taking a single large .cs file and making many smaller .cs files
    ... "Adding a layer of indirection always creates more ... I guess I feel that progressively breaking the problem down into ... down smaller we're actually hindering comprehension. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [PATCH] ehea: Optional TX/RX path optimized for SMP
    ... the driver in parallel on multiple CPUs. ... packets for an individual tcp stream on the same queue. ... On the send side we also take advantage of ehea's multiple send queue ... This alternative packet processing functionality leads to ...
    (Linux-Kernel)
  • Re: Does anyone in Delphi land NOT use OOP
    ... With regards to (multiple) inheritance, virtual methods, polymorphism etc. the various OO languages disagree, which of these properties are absolute requirements. ... I'd emphasize *intended* encapsulation of *related* functionality in a black box, with a *chance* for multiple instances of the same class/object. ... In so far modularization is a requirement for OOP, but for itself it's not sufficient to guarantee for encapsulation, data integrity etc. ... IMO the most important detail is the intention, to organize functionality in classes and objects. ...
    (borland.public.delphi.non-technical)
  • Re: localization with console application?
    ... functionality. ... like the error messages to be supported in multiple languages. ... I just had a look in the MSDN docs and if you search for either "internationalization" or "localization" you can get a lot of information (but most of it is for GUI apps). ... One thing I have found works well with console apps is to stick to UNICODE, there are then functions that can adapt themselves to either UNICODE or ANSI just by changing a few #define's, you can use *.RC files for resources... ...
    (microsoft.public.vsnet.general)
  • Re: Actually I am a little bit disappointed...
    ... > an emulation layer on top of .NET? ... functionality that is native to the drivers without having a wrapper layer, ... The NTFS file system *is* going to be superceded by WinFS which only has ... TeamBUG support for UK-BUG ...
    (borland.public.delphi.non-technical)