[ACCEPTED]-how many classes per package? methods per class? lines per method?-java

Steve McConnell in his book Code Complete 6 recommends about 7 methods per class and 5 no more lines in a method then can be viewed 4 in a single screen without scrolling.

I'm 3 not sure about classes per package.

I would 2 highly recommend reading Code Complete for 1 more information on such topics.

I think stats like that are pretty useless, how 11 does knowing the lines per method show whether 10 its any use to the project or not; i think 9 you should be looking more along the lines 8 of:

1. Do your packages encompass like classes?
2. Do your classes work as an entity on their own?
3. Do the methods within the classes function correctly and efficiently?

Surely other than memory usage, it doesn't 7 matter whether the method is large or not? the 6 other thing to look for in very protracted 5 methods is whether the stack trace is going 4 to be bigger than adding that functionality 3 to a parent method. I'd be wary of measuring 2 a projects success based on the lines of 1 code.

Robert C. Martin, who recently released 16 the book "Clean Code", states 15 that the number of lines per method should 14 be the absolutely smallest possible. Between 13 1-7 lines is a good rule of thumb.

There's 12 also a good point being made in the book 11 The ThoughtWorks Anthology, in the essay 10 “Object Calisthenics” by Jeff Bay. He suggests 9 9 pretty hardcore constraints that will 8 make you a better OO developer in the long 7 run. Read more about them here.

To answer your specific questions, these 6 are the constraints specifically to you: - No 5 more than 10 classes per package - A maximum 4 of 50 lines per class

These constraints might 3 not be ideal for all of your real projects, but 2 using them in a small (hobby?) project will 1 force you into a better practice.

Unfortunately, there's no absolute (objective) notion 17 of quality in software. Thus, there's no 16 "right" value for these. However, here are 15 a two (personal) obsevations:

3.89 classes/package 14 is very low. It means you'll be battling 13 through a complicated tree of packages.

7 12 Lines per method: Indeed sounds good. However, if 11 these number was arrived at as a result 10 of an intentional effort to reduce the line 9 count of methods then you might have ended 8 up with a single logical task being spread 7 around several private methods which will 6 make it more difficult to understand the 5 class (in certain cases). Actually in CodeComplete-2, the 4 author cites a research which discovered 3 that method length is much less importance 2 than its cyclomatic complexity and its nesting 1 level.

A useful design guideline says that each 14 class should only do one thing and do it 13 well. This will not give you a fixed number 12 of methods per class, but it will limit 11 the number and make the class easier to 10 comprehend and maintain.

For methods you 9 can adopt a similar view and aim for methods 8 that are as small as possible, but no smaller. Think 7 of it this way: if you can split the method 6 into two or more distinct parts it is obviously 5 not as small as it could be. Small methods 4 are easy to understand and by splitting 3 the code like this you will get a better 2 overview in high level methods and push 1 details to low level methods.

(note: tl;dr available at the very bottom 71 for my real opinion)

I'm not going to quote 70 any big name and say that's the right answer 69 because it's always very case dependant 68 how you do all this stuff. For example the 67 number of methods: If you're making a control 66 software for modern HD LCD TV's remote controller 65 which has about 40-50 buttons, how can you 64 break that down into classes coherently so that you 63 only have like, say, 7 methods per class?

Personally 62 I like to keep all the methods of one accessor 61 level in one class which means some utility 60 classes may end up having hundreds of methods 59 but in my opinions it's easier to do something 58 like StringUtil.escapeXMLspecialCharacters(someString) than StringUtil.XML.escapeSpecialCharacters(someString) or XMLUtil.escapeSpecialCharacters(someString). While these all are seemingly 57 OK solutions, the first one thrives (at 56 least in my mind, that is!) because it's 55 simple and very easy way to access that 54 method: You don't have to think if the string 53 you're handling contains XML or XHTML or 52 JSON or whatever, you'll just pick one method 51 from the general group of methods and that's 50 it.

Keeping on the previous TV remote analogy, lets 49 assume you do split them to various classes 48 anyway. If we allow ourselves to have 7 47 of such methods per class on average and 46 manage to group the buttons on the remote 45 to sensical groups like MenuButtons, AdjustmentButtons and 'NumberSelectorButtons', we 44 end up with 8 or so classes. That's not 43 a bad thing actually, but it gets slightly 42 confusing easily especially if they're not 41 divided to sensical groups with great care. Just 40 imagine the rants around your TVRemotes'R'Us 39 Inc. office: "Who says the power on/off 38 button is a control button?" "Who's the 37 joker who put volume +/- to menu buttons? PRE/CH 36 (the button which switches between current and previous channel and/or image source) button isn't a number button!" "The guide 35 button opens both tv guide AND navigational 34 menu depending on context, what are we going 33 to do with it!?"

So as you can hopefully 32 see from this example, using some arbitrary 31 number to limit yourself could introduce 30 some unneeded complexity and break the logical 29 flow of the application.

Before I throw in 28 my last two cents, one thing about the number 27 of lines per method: Think code as blocks. Each 26 loop is a block, each conditional is a block 25 and so on and so forth. What is the minimum 24 amount of these blocks needed for a unit 23 of code which has a single responsibility? That 22 should be your limiter, not the desire to 21 have "Seven everywhere." from number of 20 classes in package, methods in classes and 19 lines of code in methods.

And here's the 18 TL;DR:

So, my real opinion is actually this: The 17 number of classes in package should be fairly 16 low. I've been lately starting to do the 15 following but I'm not sure if I'll keep 14 up to it:

• Package foo contains interfaces and other common classes for implementations.
• Package foo.bar contains implementation of said interfaces for function bar
• Package foo.baz contains implementation of said interfaces for function baz

This usually means my whole structure 13 has a coherent (and most likely low) number 12 of classes and by reading the top level 11 class interfaces (and their comments) I 10 should be able to understand the other packages 9 too.

Methods per class: All which are needed 8 as I explained above. If your class can't 7 live without 170 methods, then let it have 6 them. Refactoring is a virtue, not something 5 that can be applied all the time.

Lines per 4 method: As low as possible, I usually end 3 up with 10 to 25 lines per method and 25 2 is a bit high for me so I'd say 10 is a 1 good balance point for that.