There are dozens of metrics, but typically all of them have shortcomings. The problem here is the notion of size: strictly speaking, to measure by size you would need to take lines of code (LOC). However, LOC greatly differs by programming language used (for the same functionality). The same applies to the number of functions: depending on programming language, you might have some more or some less. And finally, if by size you want to get an idea of complexity, the rather simple metrics quickly do not suffice anymore.

Depending on what you excactly need, I recommend that you have a deeper look on the software metrics literature and/or try out some tools. Depending on the programming language used, some powerful static analysis tools exist that will provide ample feedback – typically along with suggestions how value might be interpreted.

That's what I meant. Using design patterns would be one thing here. Do they add size and or complexity, or not? It depends...

Hi Muhammad,

there are functional size measurement methodologies addressing the issue you've asked. Function point based methodologies are around for about 30-40 years. Function point approach is mostly independent of the technology, development methodology, design of the scope and focused on the functionality delivered to users. You can have a look to our article in order to get a quick introduction to subject and related literature: "Selection of a functional sizing methodology: A telecommunications company case study" 

You can get the full text from following link or my research gate profile.

http://world-education-center.org/index.php/P-ITCS/article/view/3461/3163

Regards,

Selami

I do recommend the book "Software Metrics" by Fenton & Pfleeger (2nd edition, not 1st!!!!!). 

Given specific domains + programming languages, there are "standards" for measuring size. Note, however, that outside the domains/programming languages in questions, the usefulness of the metrics may decrease. For example, LOC is often employed to measure size of a piece of code, but this is not true for all cases. Complex code may be short and simple code (with repeated patterns) may be large in terms of LOC. For example, Grenanders code for image identification in Programming Peals (Bentley, 2000) is an example where the complexity of maintenance increases with decreasing LOC and decreasing algorithmic time complexity (the naïve algorithm is O(n^3)  with 15 LOC, an improvement is O(n^2) with 13 LOC, a divide and conques (with recursion) is O(n log n) with 21 LOC and the best is O(n) with 15 LOC). The naïve version is far more easy to understand, maintain, develop and test since it is based on the least (implicit) assumptions concering the problem domain. The final version requires a good understanding of the problem domain and is harder to maintain, develop and test. 

I recently created an assignment for the students based on the work by Fioravanti and Nesi (2001), since it addressed corrective maintenance and it can be (I believe) used and understood by undergraduates (I will see this in practice in a few weeks time if my assumptions holds!). Anyway, they have an interesting approach where they tried to validate their metric with respect to the effort of corrective maintenance of software. It raises the issue, what is the purpose of the function points. Essentially, for who will use the metric in what activity to make what decisions?

Bentley, JL 2000, Programming pearls, 2nd ed., Addison-Wesley, Reading, Mass.

Fenton, NE & Pfleeger, SL 1996, Software Metrics: A rigorous & Practical Approach, International Thomson Computer Press.

Fioravanti, F & Nesi, P 2001, ‘Estimation and prediction metrics for adaptive maintenance effort of object-oriented systems’, IEEE Transactions on Software Engineering, vol. 27, no. 12, pp. 1062–1084.

some basic ideas can be found in

https://cs.uwaterloo.ca/~palencar/cs447/lectures/Lecture22.ppt

hope it is helpful

In general, you should start by defining the objective of the measurement.

Classifying programs as small, medium, large, etc. can be done in several different ways, depending on how you want to use that classification.

For instance, if you are measuring for the purpose of estimating the development effort, or measuring for the purpose of evaluating the modifiability of the code, you will likely need different measures.

Then, you have to define the object of the development (which often depends on the objective!). In fact, different measures are applicable to different artifacts.

LoC is a measure of code.

Functional Size measures (Function Points, COSMIC, Use case points, Mark II FP, NESMA, FiSMA, etc.) are applicable to functional specifications. Of course, if you have the code, you also have (or can derive) the functional specification of the program and apply functional sizing.

Other measures, like object-oriented measures, are applicable to any artifact where the considered elements (classes, methods, inheritance relations, etc.) are present. So you can apply OO measures to OO code but also to UML models.

There is a huge amount of literature on software measures, but it is useful only if you know for what purpose you are going to measure.

Two papers on this topic that are available right here on ResearchGate include:

Kemerer, Chris F., “Reliability of Function Points Measurement: A Field Experiment”, Communications of the ACM, v. 36, n. 2, pp. 85-97, February 1993.

Kemerer, Chris F. and Ben Porter, “Improving the Reliability of Function Point Measurement: An Empirical Study”, IEEE Transactions on Software Engineering, v. 18, n. 10, pp. 1011-1024, November 1992.

Chris: these papers are very nice but do you know of any update on the topic? 20 years in software developments are quite a long time...

Tim - As you posted, there is a very large literature out there.  In responding to the OP it seemed to me that he was looking for basic information to get started, and I thought that having the papers right here on the site would be easiest for him. 

Ok, that's true. I had thought you knew of anyone how took up the topic directly. But you are right: your papers for the background and some additional literature to map to the actual situation should do.

How about calculating that yourself? Pull open source projects from repository as your samples, and calculate the correlation between #functions and #locs ?

use this link

https://books.google.iq/books?id=7NDRFgpCqV8C&pg=PA213&lpg=PA213&dq=program+size+categorizing+small+medium&source=bl&ots=cr7pryGBIw&sig=p6KakA-i5ULytuJ2P0ar6xZpBkQ&hl=en&sa=X&ei=iQX4VJyBGcPXav70gbAO&ved=0CDIQ6AEwBA#v=onepage&q=program%20size%20categorizing%20small%20medium&f=false

it is a book with the information you need EX:

very small          0-150

small                   150-300

medium             300-600

and so on..... hope this is what you are looking for as I understood form your question that you are not looking for the way to calculated rather you are looking for a standardization for your findings