Why put private fields and methods at the top of class?

Question

I've seen this de facto standard in many places in many languages, but I've never understood it - why put your private fields and methods at the top of a class declaration? Metaphorically it seems like private things should be located at the bottom (hidden) and everything public should be at the top, so that when you read through the class top to bottom you first see the public interface then the inner workings.

What is the reasoning behind this?

EDIT: Just to clarify, I don't mean the practice of declaring all members at the top of the class, but of putting private members/methods at the top of a class declaration, before anything public.

Answer 1

It probably comes from the days of C, when all variables had to be defined at the top, as part of the initialisation.

Answer 2

I always put them at the bottom.

Answer 3

Two reasons.

If they are all together at the top, they are easy to find, and easy to inspect when creating a new thing to see what naming conventions are at work and what names are and are not available.

In the C language, and in javascript, all references in code must be declared and/or defined above where they are referenced, because everything referenced must be already known. (Yes, I know, javascript only sorta.)

Answer 4

Personally, when I am trying to read somebody else's code and understand it, I like having the context that the private fields provide. It gives me a quick glimpse at the type of things they are doing and what I can expect to see. If it is done right, it can give a nice preview, almost like a table of contents to the rest of the code.

Answer 5

It's not like it's a secret that they're there. Are you afraid that someone will learn about the inner workings? If they have the source, they can learn everything they need to know about your class.

Putting them in with the others makes it easier to develop that class. All of your class variables are in one place, and so are your methods.

Answer 6

I guess it's habit. You have to declare functions and variables before you can use them so this is consistent.

On the other hand, it's the stuff you don't really want other people to be reading so it belongs at the bottom.

Answer 7

I thought the defacto standard is public methods first! atleast that is the way I write my classes. It helps me chosing the datastructures for my methods.

Answer 8

With respect to fields, it's pretty common to make all fields private (encapsulation and all that). And they're small. Since they're small, it's nice, and possible, to put them all together, and the top of a class is a nice, stable place to put them. I don't know if this is the historical justification for it - I think the C language roots probably explains that better - but it could be a reason that we keep them there.

For my own part, I tend to put private methods at the bottom, for the reasons you suggest.

Answer 9

I agree that it probably comes out of C, but it also serves a practical function.

In all things you want to learn in the order that such knowledge is required, such as learning how to add before learning how to multiply.

In the case of code, your public functions will generally reference internal private ones, and your private functions are less likely to reference the public ones (although there certainly is overlap.) So, understanding what private variables you have and what they are used for will be useful when trying to understand what the public methods are doing with those variables.

In this fashion it is also useful to understand what the private methods do before you read about the public methods which are calling them.

By and large, I believe it is a style that comes from C and earlier languages, but because it is functionally more useful where it is, I don't see any benefit in switching styles.

And, as always, breaking consistency is never a good idea unless there's an incredibly compelling reason to.

Answer 10

In OOP- there are two things - data and behavior

The private members represent the data and the public methods represent the behavior.

You can think about behavior only in the light of the data it represents So - that's why I would like to keep my data elements at the top.

Answer 11

It stems from the days when you had to declare everything - that includes functions as well as variables - before you could use them.

The internal (private) variables and functions went at the top of the file and the external (public) functions went at the bottom of the file. This meant that the public functions could reference the internal functions. If you had recursion you would have to forward reference the function by declaring it's profile.

When languages allowed the code to span several files you had to put public function and variable declarations into header files so that they could be included in the other files in the project - or indeed other projects.

Answer 12

I do this by default and if i'm honest and remember why i started doing this it is because this is how i originally learned when learning C++.