Why NOT only one class per file?

[Bruno Desthuilliers]

Nate Finch a écrit :

So, here's a view from a guy who's not a python nut and has a long
history of professional programming in other languages (C++, C, C#,
Java)
>
I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 lines of code and 50 classes in one file either.

Nope. What matters is to have
- logical grouping of code units (high cohesion)
- manageable files (not too much files, not too large files - of course
the balance depends on the project as well).

There are quite a few professional programmers here with experience on
medium to large to huge projects with different languages, you know.

 

[John Nagle]

I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 lines of code and 50 classes in one file either.

It's really an operating system thing. We think of programs as
living in text files, manipulated by programs which are basically text
editors. Python has that implicit assumption. There have been
systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.

The assumption that programs are text files is deeply embedded in
programming culture, so deeply that it's seldom questioned. Programs
are the last refuge of non-rich media. You can't even embed an image
in your program; it has to be in some completely separate file.

Interestingly, PHP breaks this model; PHP programs are web pages.
They may be on to something.

John Nagle

 

[Paddy]

It's really an operating system thing. We think of programs as
living in text files, manipulated by programs which are basically text
editors. Python has that implicit assumption. There have been
systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.

The assumption that programs are text files is deeply embedded in
programming culture, so deeply that it's seldom questioned. Programs
are the last refuge of non-rich media. You can't even embed an image
in your program; it has to be in some completely separate file.

Interestingly, PHP breaks this model; PHP programs are web pages.
They may be on to something.

John Nagle

Some languages (Specman e, and I think Perl), have the concept of
begin and end end markers. The interpreted/compiled code is what is
seen between those markers allowing the source to be embedded in
other
text.

 

[Nate Finch]

Nate Finch a écrit :


There are quite a few professional programmers here with experience on
medium to large to huge projects with different languages, you know.

Sorry, I meant to go back and edit that phrase to sound less
condescending. I know there are a lot of professional programmers on
here, and I didn't mean to imply otherwise. It wasn't supposed to be
a contrast to everyone, just introducing myself.

I totally agree with you... there's a balance between too many files
and files that are too large.

As to the guy who writes 1000+ line classes .... dude, refactor some.
You're trying to make the class do too much, almost by definition.

We have *some* classes that big, and they're marked as "needs
refactor". It's certainly not a common occurance, though. Usually
they're UI classes, since they require a lot of verbose positioning of
elements and hooking of events.


And while people are reading this thread, let me plug my other thread,
asking about absolute_import. I'd really love some help

-Nate

 

[Steve Holden]

John Nagle a écrit :

Nate Finch wrote:

[...]

Interestingly, PHP breaks this model; PHP programs are web pages.

Err... Actually, "web pages" *are* text files. And FWIW, in most php
programs (at least the clean ones), the application logic is in separate
files, and the 'rendering' code (views, templates, call them what you
like) are seldom full html documents.

And it's perfectly possible to write a PHP program that isn't a web
page. It's just that PHP is such an awful language nobody chooses to do it.

Perhaps I'm not being fair to PHP. It's just been pushed so far beyond
its original design limits that it's screamingly uncomfortable to use.

regards
Steve

 

[Bruno Desthuilliers]

Sherm Pendley a écrit :

Yes, but the pain in that case comes from having hundreds of trivial
classes,

The fact that a class is short doesn't imply it's trivial.

not from the way in which the source for them is organized.

I have to disagree. Having several, closely related objects (ie:
classes, functions, etc) in a same file allow to "see the big picture",
and avoids the mental overhead of navigating thru files, directories,
opened windows etc.

Of course, it doesn't mean that one should store the whole program in a
single monster file - I usually start to rearrange things when the file
grows bigger than one thousand lines.

Neither would I. But then, I would describe the existence of all those
files as just the symptom - the real problem being the design that needs
all of those hundreds of trivial classes in the first place.

In my book, it's huge classes and methods that are usually a smell of a
design problem. Specially with languages like Python or Ruby. Factoring
out code duplication usually leads to lot of small objects - and also to
a significant reduction of the code base's size.

Granted, I know very little of Python. It may be the case that Python
encourages the use of hundreds of "little classes"

Python being very expressive, and having powerful metaprogramming
features, there's usually much less boilerplate (than in languages like
Java) for a same result. So yes, it's quite usual to have small classes
and functions.

- and if that is the
case, then I agree, storing each one in its own file would be rather
absurd.

Indeed. That's the point (or at least part of it).

I'm more accustomed to writing classes that tend to be larger - hundreds
if not thousands of lines each,

It sometimes happens that a class or function needs to be much bigger
than the average. So be it. But if I found myself writing
thousands-lines classes in Python, I'd start to seriously consider
rethinking the whole stuff.... Heck, I have very few *modules* that are
more than one thousand lines long, and almost never a single class per
module.

or more -

In Python ???

 

[Bruno Desthuilliers]

John Nagle a écrit :

It's really an operating system thing. We think of programs as
living in text files, manipulated by programs which are basically text
editors. Python has that implicit assumption. There have been
systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.
>
The assumption that programs are text files is deeply embedded in
programming culture, so deeply that it's seldom questioned. Programs
are the last refuge of non-rich media. You can't even embed an image
in your program; it has to be in some completely separate file.

Having source code as text files may not be such a bad thing. Diffing,
grepping and versioning binary files is not that easy...

Interestingly, PHP breaks this model; PHP programs are web pages.

Err... Actually, "web pages" *are* text files. And FWIW, in most php
programs (at least the clean ones), the application logic is in separate
files, and the 'rendering' code (views, templates, call them what you
like) are seldom full html documents.

 

[Sherm Pendley]

Sherm Pendley a écrit :

In my book, it's huge classes and methods that are usually a smell of
a design problem.

Obviously we're reading different books.

But that's OK - I'm not on a crusade to convince everyone to work my way.
If "one class per file" doesn't work well for you, don't write that way.
All I'm saying is, what works well for you isn't necessarily what works
well for everyone.

sherm--

 

[Sherm Pendley]

As to the guy who writes 1000+ line classes .... dude, refactor some.
You're trying to make the class do too much, almost by definition.

You haven't even seen my code, you don't even know what language it's in,
but you're telling me it's wrong?

Wow - and I thought *I* was arrogant.

sherm--

 

[Bruno Desthuilliers]

Steve Holden a écrit :

John Nagle a écrit :

Nate Finch wrote:

[...]

Interestingly, PHP breaks this model; PHP programs are web pages.

Err... Actually, "web pages" *are* text files. And FWIW, in most php
programs (at least the clean ones), the application logic is in
separate files, and the 'rendering' code (views, templates, call them
what you like) are seldom full html documents.

And it's perfectly possible to write a PHP program that isn't a web
page. It's just that PHP is such an awful language nobody chooses to do it.

Perhaps I'm not being fair to PHP. It's just been pushed so far beyond
its original design limits that it's screamingly uncomfortable to use.

original design ? Which original design ?-)

 

[Bruno Desthuilliers]

Sherm Pendley a écrit :

Obviously we're reading different books.

Obviously. But I didn't gain this knowledge from books.

FWIW, I'd be interested if you'd let us know about any book pretending
that monster classes are good design !-)

But that's OK - I'm not on a crusade to convince everyone to work my way.
If "one class per file" doesn't work well for you, don't write that way.
All I'm saying is, what works well for you isn't necessarily what works
well for everyone.

It seems that it works well for almost anyone having some real-world
experience with languages like Python. Experience with C++, Java,
ObjectPascal, (insert your favorite verbose low-level language here) may
not apply here.

 

[Carl Banks]

A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummoxed.

A: Because you don't have to.

Less smart aleck: Python allows programmers to put more than one class
per file. Given that freedom, most people didn't obey one-to-one
correspondence between classes and files. Therefore, it's the more
common idiom in Python.

I tried to rationalize this Python idiom by claiming a file--a single
module--makes for a great container of code which is logically tied
together, such as a class and its subclasses. He posited that
directories (packages) can tie the files together just as well,

Which is not incorrect.

and by
having the classes as separate files, he can "diff" them to see how
they differ, something he wouldn't be able to do with the code all in
one file.

I agree with Bruno: feeling the need to do this is a big red flag that
the code is way too cut-and-paste.

(diff'ing different versions is useful, of course, but you can
usefully diff modules with many classes in them.)

I also offered that having related classes under one file gives more
direct access to those classes, e.g.:

[snip examples]

He doesn't find my arguments convincing, so I thought I'd ask here to
see why the Python idiom is the way it is: why should we NOT be
placing classes in their own separate files?

There's no overwhelming reason not to, IMO. As long you have some
organization, be it with packages or modules, everything's ok. Most
things you have to gain or lose by doing one way or the other are of
minor importance.


Carl Banks

 

[John Nagle]

John Nagle a écrit :

Having source code as text files may not be such a bad thing. Diffing,
grepping and versioning binary files is not that easy...

There are tools for that sort of thing, although they're not well
known in the open source world. Check out "http://www.alienbrain.com"
and view the demo. Alienbrain is used for configuration management on
major game development projects, where there are dozens of different
types of "assets", from code to motion capture data to images to audio
to video to 3D geometry. All the stuff programmers expect, like build
management, version control, history, and differencing, are all there.
But they're not limited to text files.

I'm not suggesting this for Python, but it's interesting to consider
that perhaps web development needs tools more like this.

John Nagle

 

[Sherm Pendley]

Sherm Pendley a écrit :

Obviously. But I didn't gain this knowledge from books.

Obviously, you have no sense of humor.

FWIW, I'd be interested if you'd let us know about any book pretending
that monster classes are good design !-)

You've already decided that "monster classes" are bad design, and that
anything conflicting with your belief is mere pretense. Why should I waste
my time debating when you've already made up your mind?

It seems that it works well for almost anyone having some real-world
experience with languages like Python.

I didn't say otherwise. You're arguing a false dichotomy; the fact that one
approach works well does not prove that others won't work equally well. I'm
not saying that your preferred style is wrong; I'm just saying that it's a
matter of preference, not a universal truth.

sherm--

 

[Malcolm Dew-Jones]

Chris Lasher ([email protected]) wrote:
: A friend of mine with a programming background in Java and Perl places
: each class in its own separate file in .

Java doesn't actually require one class per file, it requires one public
class per file. You can have any number of helper classes in the same
file.

Perl doesn't require anything, and files and classes are almost entirely
different things (except by useful convention).

I'm only just getting into python, so I have no opinions yet.

 

[Alex Martelli]

systems that didn't work that way, in which the program source was
manipulated within the language environment, in a more structured
fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
built that way. But it never really caught on.

APL was that way, too. And now the ACM wants to dissolve the APL SIG --
there just isn't anything much happening there any more:-(


Alex

 

[Paul Rubin]

Interestingly, PHP breaks this model; PHP programs are web pages.
They may be on to something.

See also "literate programming", including the version built into Haskell.

 

[Steven D'Aprano]

A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummoxed.

Hah! Writing one class per file is for wimps! When I program, I write one
*method* per file, then import them and build the class at runtime.

I have a friend who writes one *line* per file, then pulls them all
together with exec(), but that's just being stupid.

 

[Bart Willems]

Hah! Writing one class per file is for wimps! When I program, I write one
*method* per file, then import them and build the class at runtime.

I have a friend who writes one *line* per file, then pulls them all
together with exec(), but that's just being stupid.

I guess you're one of those sissies who uses EDLIN as an editor.

REAL programmers use COPY CON: ...

 

[Dennis Lee Bieber]

REAL programmers use COPY CON: ...

For one liners, wouldn't

ECHO the text line >the.file

be more appropriate? <G>
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/