In your object-oriented language, what guidelines do you follow for grouping classes into a single file? Do you always give each class a seperate file? Do you put tightly coupled classes together? Have you ever specified a couple of implementations of an interface in one file? Do you do it based on how many lines of code the implementation might be or how "cluttered" it might look to the user of the class? Or would the user prefer to have everything on one place?
Personally, I suggest one class per file unless the secondary classes are private to the primary class in the file. For example, a nested class in C# would remain in the parent classes file, but utility classes that might be useful elsewhere get broken into their own file or even namespace.
The key is to understand your environment and where people will look for things. If there is an established methodology in place, think carefully before you upset it. If your coworkers expect that related, tightly bound classes will be in a single document, having to search for them could be annoying (although with modern IDEs it shouldn't be a problem).
An additional reason for breaking things into more files rather than less is version control. If you make a small change, it should change only a small file where possible. If you make a sweeping change, it is obvious looking at the logs because of all the files (and indirectly, classes) that were affected are noted.
I think best practices in all OO languages I have ever used is to have one class in one file. I believe some languages may require this but I am not sure of that fact. But I would say that one class per file, and the name of the file matching the name of the class (as well as the directory structure matching the package structure for the most part) is best-practice.
1 class = 2 files. An .h and a .c, you kids are so lucky :)
There is no hard and fast rule that must always be followed (unless a particular language enforces it). There are good reasons for having just one class, or having multiple classes in a file. And it does depend on the language.
In C# and Java people tend to stick to one file per class.
I'd say in C++ though I often put multiple classes in one file. Often those classes are small and very related. Eg. One class for each message in some communications protocol. In this case a file for each would mean a lot of files and actually make maintenance and reading of the code more difficult than if they were in one file.
In C++ the implementation of a class is separate from the class definition, so each class { /body/ } is smaller than in other language and that means classes are more conveniently sized for grouping together in one file.
In C++ if you're writing a library (eg the standard template library) , you can put all the classes in one file. Users only need to include the one header file and they get all the classes then, so its easier for them to work with.
There's a balance. The answer is whatever is most easy to comprehend and maintain. By default it makes sense to have one class per file, but there are plenty of cases when it's more practical to work with a related set of classes if they are defined in one file.
I put classes into the same file if they belong together, either for techinical or aesthetic reasons. For example, in an application that provides a plugin interface, the classes Plugin (base class for plugins) and PluginManager I would usually put together in the same file. However, if the file grows too big for my taste, I would split them into separate file.
I note that I write code mostly in Python at the moment, and this influences my design. Python is very flexible in how I get to divide stuff into modules, and has good tools for managing the name spaces of things. For example, I usually put all the code for an application in a Python module (a directory with __init__.py) and have the module import specific names from sub-modules. The API is then something like applib.PluginManager rather than applib.pluginstuff.PluginManager.
This makes it easy to move things around, which also allows me to not be so fussy when I am creating the design: I can always fix things later.
One class = one file. Always. Apart from when one class = multiple files in C#, or a class contains inner classes etc of course ;)
One per a file is our standard. The only exception is that for a class and it's typed collection we put those together.
Over time I've come to relize, that "small class" always tend to grow. And then you'll want to split them up, confusing everyone else on the team (and your self).
I try to keep one class per file (like most of the above), unless they are small classes. If there are a lot of them, I may split them into subjects otherwise. But usually I just keep them all in one file with code-folding in editors. For my private hacks, it just isn't worth the (minimal) effort to me.
One class per file seems to be the standard. This is the way that I usually do it as well.
There have been a few times where I've strayed away from this. Particularly when a smaller class is a member of another class. For example, when designing a data structure, I would likely implement a "node" class within the same file as the "bigstructure" class.
In your object-oriented language, what guidelines do you follow for grouping classes into a single file?
It depends. In team work I try to follow team standards; in solo work I tend more towards whatever-I-please.
In solo work, then ...
Do you always give each class a seperate file? Do you put tightly coupled classes together? Have you ever specified a couple of implementations of an interface in one file?
No. Sometimes. Yes.
Do you do it based on how many lines of code the implementation might be or how "cluttered" it might look to the user of the class? Or would the user prefer to have everything on one place?
It's mostly based on:
How easy is it to navigate? A huge long source file, with many classes, is more difficult.
How easy is it to edit? When editing multiple, short, related classes, it may be easier if they're all in one source file with a splitter than if they're in several source files, given that I run my text editor maximized showing one source file at a time.
I prefer 1 to 1 for classes unless the inner class will be entirely private.
Even then I usually break it out for ease of finding it and tracking changes in SVN.
Related
Several parts of my library come with "convenience" functions. For example, a container class might have a function to parse information from a string. These functions are not necessarily needed (or wanted) all the time, so I'd like to put them in separate files so they can be included or left out according to the users' needs.
How should this be structured? Should I put all the "convenience" stuff in header files in a separate folder? Or perhaps it belongs in a completely separate library...?
How do big libraries (like Boost) handle this sort of thing? Or do they just avoid it altogether?
"Should" is a word which tends to provoke religious responses, but I think you'll be better off thinking about this as though you were a user of your library.
How would you want it to be structured? Everything in one api so you can find it, or scattered around the classpath?
Is there any real reason to even consider putting (for example) your container class's "parseString" method anywhere else than in the container class?
It's common for library providers to organize their library into logical pieces, but then provide a way to include the entire library in one go (in C/C++, a single header file; in Ruby, a single include, &c.). This allows for good cohesion, and allows library users to include just the pieces they need, if they desire.
What is best practice for the directory/location of your interfaces? (as in implements)
in the folder with the class you are interfacing? an interface folder in the source root?
Generally speaking, you shouldn't differentiate between an interface and a class when choosing package structure.
Since you're almost certainly using interfaces to make your API cleaner, you should imagine that you are giving your code to another experienced AS3 coder; where would they expect to find the class/interface within a SWC? There's no reason that they should differentiate between an interface and a class, given that they can't see the code anyway.
This isn't a question with a back-and-white answer. That said, it is my personal opinion that it makes most sense for an interface to live in the same package as the classes which implement it (or as close as possible). That way others who use your code can infer some thing about the interface and its intended use from the package structure.
When all the interfaces are in an "interface" folder on the root 1 - that folder can get really big & ugly, 2 - the interfaces are totally disconnected from all the related files, so it's more difficult to move them around as a group, 3 - your only clue about what the interface does (without actually opening it or importing it and examining its docs and members) is the file name.
I currently put them in an interface folder but this wont help readability for people who do not know the code base no more than lumping all of your implementation classes in a folder called implementation.
How do you guys logically sort your project interfaces.
I assume you're talking about the kind of interfaces that classes implement in OO languages.
I'd say it's better to name the folder by function, if you really want to separate the interface from implementing classes - call the folder 'listeners' or whatever these interfaces represent. The fact they're interfaces (or abstract classes) should be obvious from the way they're named and used.
Then again, if it's not some form of a framework other people will use, but end up with an interface and a two or three implementing classes you write and leave them be, you might as well stick them all together in the same package. I don't think that making a package for a single class/interface does much for clarity.
Not part of the question but I'll write it anyway - I'm also not a fan of the "I" prefix for interfaces. If it's not obvious without it, then it could probably use a different name/structure.
I'm not referring to the indentation or the directory structure but the actual file itself.
Do you arrange your members and methods alphabetically? Maybe in their order of use or order of complex logic (either ascending or descending)? Is there any rhyme to your madness?
I'm thinking about making the switch to alphabetically but some situations would just madden me:
var _height
var _properties
var _width
width and height should definitely be grouped together... but sometimes finding the right method in a larger file can be pretty disheartening.
What do you do?
I tend to be disorganized. I certainly don't arrange my variables alphabetically. And with C#, I am even less organized because some variables I use stuff_like_this, and with properties I might DoItLikeThis. It kind of drives me mad at times, but in the end I like letting the IDE features do the work for me. Visual Studio is incredibly nice, and being able to just right click on a variable to go to its definition, or see everywhere in the code that it's being used is downright awesome. I don't know what IDE you use, but hopefully it's got similar features. In the end, I care less about the organization and really need to worry if my design is fundamentally sound (and that part usually takes me a few tries to get right).
I would suggest not trying to apply any sweeping general rules to your code. Rather, on a case-by-case basis, organize it in a way that makes sense. In the example you give, purely alphabetical would not make sense. In other cases, it would.
Methods: public first, then private. Methods which are related (e.g. getHeight(), getWidth(), getArea()) are placed near each other. If there is a hierarchal relationship between methods, then high-level before the low level (e.g. getArea() uses getWidth() so it's placed before it)
variables: similar to functions, public first, then private. Grouped according to context.
Alphabetical? I don't like it. It can be a nightmare when reading / modifying the code. I cannot tell whether a function's name is sqrt() or calculateSqrt(), so I won't enjoy looking for it. If the functions are organized according to context, it will be much easier to find them.
Generally order the members by their nature (constants, fields, constructors, methods) and then by their visibility (private, protected, public).
For finding the right thing I rely a lot on a modern IDE's capabilities (e.g. Visual Studio + Resharper)
Functions are topologically sorted with the "root" at the bottom of the file.
Variables hardly matter -- if a single "unit" (function, class, etc.) has enough variables for their arrangement to mean anything, that's probably something that needs fixing in itself.
I organize my code is by type of the elements, meaning that all the methods are at one place (at the end of the file, that is), all the constructor in one (before methods), etc. The same goes for variables, constants, enums etc. Usually I place private variables first and others after them, but that's not a strict rule. Also by nature code related to each other often ends up at the same place, but that's just because it is easiest.
I don't bother keeping my code in alphabetical order as I do that easily in the Eclipse outline view. However, if the editor does not support this, then I might use alphabetical order. Well, at least for bigger files.
This has been asked before (question no. 308581), but that particular question and the answers are a bit C++ specific and a lot of things there are not really relevant in languages like Java or C#.
The thing is, that even after refactorization, I find that there is a bit of mess in my source code files. I mean, the function bodies are alright, but I'm not quite happy with the way the functions themselves are ordered. Of course, in an IDE like Visual Studio it is relatively easy to find a member if you remember how it is called, but this is not always the case.
I've tried a couple of approaches like putting public methods first but that the drawback of this approach is that a function at the top of the file ends up calling an other private function at the bottom of the file so I end up scrolling all the time.
Another approach is to try to group related methods together (maybe into regions) but obviously this has its limits as if there are many non-related methods in the same class then maybe it's time to break up the class to two or more smaller classes.
So consider this: your code has been refactored properly so that it satisfies all the requirements mentioned in Code Complete, but you would still like to reorder your methods for ergonomic purposes. What's your approach?
(Actually, while not exactly a technical problem, this is problem really annoys the hell out of me so I would be really grateful if someone could come up with a good approach)
Actually I totally rely on the navigation functionality of my IDE, i.e. Visual Studio. Most of the time I use F12 to jump to the declaration (or Shift-F12 to find all references) and the Ctrl+- to jump back.
The reason for that is that most of the time I am working on code that I haven't written myself and I don't want to spend my time re-ordering methods and fields.
P.S.: And I also use RockScroll, a VS add-in which makes navigating and scrolling large files quite easy
If you're really having problems scrolling and finding, it's possible you're suffering from god class syndrome.
Fwiw, I personally tend to go with:
class
{
#statics (if any)
#constructor
#destructor (if any)
#member variables
#properties (if any)
#public methods (overrides, etc, first then extensions)
#private (aka helper) methods (if any)
}
And I have no aversion to region blocks, nor comments, so make free use of both to denote relationships.
From my (Java) point of view I would say constructors, public methods, private methods, in that order. I always try to group methods implementing a certain interface together.
My favorite weapon of choice is IntelliJ IDEA, which has some nice possibilities to fold methods bodies so it is quite easy to display two methods directly above each other even when their actual position in the source file is 700 lines apart.
I would be careful with monkeying around with the position of methods in the actual source. Your IDE should give you the ability to view the source in the way you want. This is especially relevant when working on a project where developers can use their IDE of choice.
My order, here it comes.
I usually put statics first.
Next come member variables and properties, a property that accesses one specific member is grouped together with this member. I try to group related information together, for example all strings that contain path information.
Third is the constructor (or constructors if you have several).
After that follow the methods. Those are ordered by whatever appears logical for that specific class. I often group methods by their access level: private, protected, public. But I recently had a class that needed to override a lot of methods from its base class. Since I was doing a lot of work there, I put them together in one group, regardless of their access level.
My recommendation: Order your classes so that it helps your workflow. Do not simply order them, just to have order. The time spent on ordering should be an investment that helps you save more time that you would otherwise need to scroll up and down.
In C# I use #region to seperate those groups from each other, but that is a matter of taste. There are a lot of people who don't like regions. I do.
I place the most recent method I just created on top of the class. That way when I open the project, I'm back at the last method I'm developing. Easier for me to get back "in the zone."
It also reflected the fact that the method(which uses other methods) I just created is the topmost layer of other methods.
Group related functions together, don't be hard-pressed to put all private functions at the bottom. Likewise, imitate the design rationale of C#'s properties, related functions should be in close proximity to each other, the C# language construct for properties reinforces that idea.
P.S.
If only C# can nest functions like Pascal or Delphi. Maybe Anders Hejlsberg can put it in C#, he also invented Turbo Pascal and Delphi :-) D language has nested functions.
A few years ago I spent far too much time pondering this question, and came up with a horrendously complex system for ordering the declarations within a class. The order would depend on the access specifier, whether a method or field was static, transient, volatile etc.
It wasn't worth it. IMHO you get no real benefit from such a complex arrangement.
What I do nowadays is much simpler:
Constructors (default constructor first, otherwise order doesn't matter.)
Methods, sorted by name (static vs. non-static doesn't matter, nor abstract vs. concrete, virtual vs. final etc.)
Inner classes, sorted by name (interface vs. class etc. doesn't matter)
Fields, sorted by name (static vs. non-static doesn't matter.) Optionally constants (public static final) first, but this is not essential.
i pretty sure there was a visual studio addin that could re-order the class members in the code.
so i.e. ctors on the top of the class then static methods then instance methods...
something like that
unfortunately i can't remember the name of this addin! i also think that this addin was for free!
maybe someone other can help us out?
My personal take for structuring a class is as follows:
I'm strict with
constants and static fields first, in alpha order
non-private inner classes and enums in alpha order
fields (and attributes where applicable), in alpha order
ctors (and dtors where applicable)
static methods and factory methods
methods below, in alpha order, regardless of visibility.
I use the auto-formatting capabilities of an IDE at all times. So I'm constantly hitting Ctrl+Shift+F when I'm working. I export auto-formatting capabilities in an xml file which I carry with me everywhere.
It helps down the lane when doing merges and rebases. And it is the type of thing you can automate in your IDE or build process so that you don't have to make a brain cell sweat for it.
I'm not claiming MY WAY is the way. But pick something, configure it, use it consistently until it becomes a reflex, and thus forget about it.