On Feb 19, 2019, at 14:13, Stefano Stabellini <sstabell...@kernel.org> wrote:
> 
>> On Mon, 18 Feb 2019, Lars Kurth wrote:
>>      On 18 Feb 2019, at 12:16, George Dunlap <george.dun...@citrix.com> 
>> wrote:
>> 
>> On 2/18/19 12:11 PM, George Dunlap wrote:
>>      On 2/18/19 12:01 PM, Andrew Cooper wrote:
>>            On 18/02/2019 11:57, Wei Liu wrote:
>>                  On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>> 
>>                              On 18 Feb 2019, at 11:30, George Dunlap
>>                              <george.dun...@citrix.com> wrote:
>> 
>>                              On 2/18/19 11:23 AM, Wei Liu wrote:
>>                                    On Mon, Feb 18, 2019 at 11:17:56AM +0000, 
>> Lars
>>                                    Kurth wrote:
>>                                          Thank you Wei. It's interesting 
>> though
>>                                          that the full vs HVM only is almost
>>                                          identical in terms of SLOC's
>>                                          Lars
>> 
>>                                    The cloc target counts the files in the 
>> dependency
>>                                    graph generated by
>>                                    make.
>> 
>>                        Do we know for sure that CLOC counts everything in a 
>> file or does it honour
>>                        the pre-processor settings?
>> 
>>                  We certainly don't feed any preprocessor defines to it. I 
>> doubt it
>>                  understand C to that level of details anyway.
>> 
>> 
>>            LoC isn't a fantastic metric under any circumstance.
>> 
>>            Bigger code is definitely better, if the reason it is bigger is 
>> because
>>            it is because it is formatted for readability/clarity etc.
>> 
>>            Attempting to optimise for smaller LoC, other than making entire
>>            functional areas optional, is usually short sighted.
>> 
>> 
>>      For instance, we could probably decrease the LoC by nearly 20k by
>>      changing the style not to give the opening bracket its own line:
>> 
>>      $ find . -name '*.c' | xargs grep '^[[:space:]]*{' | wc -l
>>      19896
>>      $ find . -name '*.[ch]' | xargs grep '^[[:space:]]*{' | wc -l
>>      21847
>> 
>> 
>> This is hypervisor only BTW (run from xen.git/xen).
>> 
>> It is a bit mind-boggling to think that there are more open brackets in
>> the Xen code base than there is PV-specific code. O_o
>> 
>> 
>> As we have the same coding conventions across hypervisor code, that 
>> shouldn't make a difference
> 
> This is amazing, in a terrible kind of way: all our numbers will be
> inflated by 20K!! For Xen on Arm is almost 50%! I am half-thinking we
> should add xargs grep '^[[:space:]]*{' to the make cloc target.

UCC (Unified Code Count) [1] can measure/diff logical SLOC for several 
languages.

Rich

[1] Papers 
http://csse.usc.edu/TECHRPTS/2007/usc-csse-2007-737/usc-csse-2007-737.pdf
http://csse.usc.edu/csse/event/2012/COCOMO/presentations/TOR-2010(3906)-72_Library.pdf
http://www.nguyenvvu.net/wp-content/uploads/2015/07/UCC_Tool_Description.pdf

[2] Source
http://csse.usc.edu/ucc_new/wordpress/2018/07/26/ucc-version-2018-07/

[3] Build
g++ ./src/*.cpp -o UCC -std=c++0x -DUNIX -O3

[4] Run
UCC -dir xen *.c -outdir report

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to