Know how many lines of code you have in an Xcode project?

Question

I've got quite a big project and eventually I finished it. I'm just curious to know how many lines of code there are altogether in my project. I'm using Xcode 3. So can you actually find out how many lines of code have been compiled?

Answer 1

Open up Terminal.app, go into your project's root directory, and run this command:

For Swift only:

find . \( -iname \*.swift \) -exec wc -l '{}' \+

For Obj-C only:

find . \( -iname \*.m -o -iname \*.mm -o -iname \*.h \) -exec wc -l '{}' \+

For Obj-C + Swift:

find . \( -iname \*.m -o -iname \*.mm -o -iname \*.h -o -iname \*.swift \) -exec wc -l '{}' \+

For Obj-C + Swift + C + C++:

find . \( -iname \*.m -o -iname \*.mm -o -iname \*.c -o -iname \*.cc -o -iname \*.h -o -iname \*.hh -o -iname \*.hpp -o -iname \*.cpp -o -iname \*.swift \) -exec wc -l '{}' \+

Terminal quick tips:
ls: list directory contents
cd: change directory
Press tab to autocomplete
Remember to put "\" backslash before spaces
I suggest going one folder down from the main project so you get rid of code count from the frameworks

Answer 2

Open up Terminal.app, cd into your project's root directory, and run this command:

find . \( -iname \*.m -o -iname \*.mm -o -iname \*.c -o -iname \*.cc -o -iname \*.h \) -exec wc -l '{}' \+

If you other file types you also want to include in your count, then add more -o \*.ext clauses.

Answer 3

You can use sloccount or cloc to do this, they are both compatible with Objective-C code.

I recommend using sloccount, you can get a nice HTML report if you also use Jenkins. The HTML report will enable you to drill down to the different directories and files.

This is a command line for just having an overview of your code, if you are in the root dir of your Xcode project:

    sloccount --duplicates --wide YOUR-TARGET-NAME

And if you want to generate a report to use in Jenkins, just add the --details flag:

    sloccount --duplicates --wide --details YOUR-TARGET-NAME > build/sloccount.sc

and install the Jenkins plugin for sloccount via Jenkins UI.

You will be able to see examples of such reports in Jenkins in this blog article (disclaimer: I am the author): http://blog.octo.com/en/jenkins-quality-dashboard-ios-development/#step1-1.

Answer 4

One way is to load a copy into Xcode and use "Project Analyzer for Xcode 4". Search for "Xcode" in the Apple Mac App Store. I have not used this program but I happened to see it yesterday when I was searching for Xcode related apps in the Mac App Store.

Hope that helps.

Answer 5

A bash script which finds line count of files WITHOUT COMMENTS AND EMPTY LINES. The script doesn't count comments which start with //. Copy the script to your project folder and run by sh scriptname.sh.

For swift change \( -iname \*.m -o -iname \*.mm -o -iname \*.h \) to \( -iname \*.swift \)

# $excluded is a regex for paths to exclude from line counting
excluded="some_dir_name\|some_dir_name2\|lib\|thisfile"

countLines(){
  # $total is the total lines of code counted
  total=0
  # -mindepth exclues the current directory (".")
  for file in `find . -mindepth 1 \( -iname \*.m -o -iname \*.mm -o -iname \*.h \) | grep -v "$excluded"`; do
    # First sed: only count lines of code that are not commented with //
    # Second sed: don't count blank lines
    # $numLines is the lines of code
    numLines=`cat $file | sed '/\/\//d' | sed '/^\s*$/d' | wc -l`

    # To exclude only blank lines and count comment lines, uncomment this:
    #numLines=`cat $file | sed '/^\s*$/d' | wc -l`

    total=$(($total + $numLines))
    echo "  " $numLines $file
  done
  echo "  " $total in total
}

countLines

Answer 6

I'm not sure about any tools that plug into Xcode directly (why are you still using Xcode 3 when 4.1 is freely available on Lion?), but I find that the command-line cloc tool works well with Objective-C code.

Answer 7

A really nice unix command is xargs. See the "pipe to xargs below". For example:

find . \( -iname \*.m -o -iname \*.mm -o -iname \*.h -o -iname \*.swift \)  | xargs wc -l

Oddly, I'll have to figure out though why this answer comes out a tiny bit lower for me than the answer from @Esqarrouth