Assessing the meaning of a metric in a binary design I try to assess the meaning of  a software metric lines of code on bug density with the help of statistical methods. I have information on bugs and other needed software measures for several years. This is my current approach, which I hope can be cross-validated here:
H_0 (null-hypotheses): Bugs are uniformly distributed (in respect of lines of code)
H_1: Bugs are not uniformly distributed (in respect of lines of code)
For a time-window x, I have the number of bugs and information on all source files. I now split the source files into two groups: small files and large files - each group has the same amount of lines (50% of total lines). This makes it a binary experiment and the probability, under the assumption that bugs are uniformly distributed, is 0.5 if a bug falls into the small or large file group.

This experiment is now comparable with a coin toss: I have the number of total bugs n, the number of bugs found in the group t, the expected number of bugs (mean: 0.5n), and the standard deviation (sqrt(p(1-p)/n)). I can then calculate the number of standard deviations the number of actual bugs deviates and read its probability from the table.
However, what I'm not sure of, is whether it does make a difference if I split the data into different time-windows. In other words, does it make a difference to the result, if I make this experiment one time (with data over several years) with 50000 bugs or if I split it into lets say 5 experiments with 10000 bugs each?
Thanks for any suggestions and advice!
 A: As discussed in the comments, the procedure proposed can be problematic to test the hypothesis. Moreover, given the limited information, i.e. number of bugs per file and file size, I do not know if we can really test the desired hypothesis. What we can instead is to test is if the bugs depends on the source files, and this is somehow related to the initial hypothesis.
Lets rewrite the null as $H_0$: the probability of finding a bug in a line does not depend on the source file. If we do not reject this last hypothesis, then we clearly can not have the bugs uniformly distributed in the lines (because they depend on the source files).
Assume we have $\{1,\ldots, F\}$ files, each one consisting of $(b_i, n_i)$, where $b_i$ is the number of bugs in the $i$-th file and $n_i$ is the number of lines. Assuming that lines the lines are independent of each other and it contains a bug with probability $p_i$ for the $i$-th source file, we have $b_i \sim Binom(n_i, p_i)$. In this scenario, the hypothesis $H_0$ translates to
$H_0: p_i = p,\quad i\,\in\,\{1,\ldots,F\}$.
That is, the probability of observing a bug does not depend on the file. Letting $N = \sum_{i=1}^F n_i$ be the total number of lines and $B = \sum_{i=1}^F b_i$ the total number of bugs, we estimate the probability of having a bug in a line as $\hat{p} = \frac{B}{N}$.
To test the null, we can use a Chi-squared test for homogeneity. This basically compares the expected number of bugs $i$-th line $E_i = n_i\frac{B}{N}$ under the null-hypothesis vs what you actually observed $b_i$ for all files. You calculate the test statistic, compute the p-value using the distribution of $\chi^2$ with $F-1$ degrees of freedom and compare to your significance level.
Rejecting the test implies rejecting that bugs are uniformly distributed in lines. Not rejecting does not imply the bugs are uniformly distributed in lines. They could depend on other variables, for instance, the type of assertions the line contains (function call, assignment, declaration, macro, etc).
