On Wed, Mar 29, 2017 at 10:54:36AM -0400, a...@php.net wrote: > > WTF. Did you write a program to generate this much? I've seen > > operating systems that ran really well at that line count. > > Not sure I follow your q, but yes some of it is codegen (the stdio > scripting part). > > My definition of sloc is roughly `cat *.c *.h | wc -l`. Using this > metric on other editors:
As others already have pointed out this metric isn't that useful in itself. What it does indicate is that some projects are beyond repair (e.g. vim). You should at very least use something like cloc(1) which besides comments also filters out duplicated files. Mind you, it is still a bad metric. Also I felt like your numbers are a bit off/misleading, hence I took a quick look. > vim: 430k No comment required ... > kakoune: 27k Comparing SLOC of different programming languages makes even less sense. With C++ you can fit way more complexity into the same number of lines. The standard library includes a lot more functionality. This doesn't even yet take boost into consideration. > nano: 25k > vis: 22k This includes stuff like the vis-digraph (basically 1 large lookup table) and vis-menu utilities. You didn't include fzf(1) in your mle tally, did you? If you are fine with disabling more compile time features you could further subtract: 2012 vis-digraph.c 605 vis-menu.c 118 text-regex-tre.c 217 ui-terminal-vt100.c 2869 vis-lua.c 5821 total > mle: 10k After having a quick look, this also feels misleading. Your suggested shell counting glob doesn't include the core data structure of your editor because it was moved to an external library. A more accurate result would be: $ wc -l *.[ch] mlbuf/*.[ch] ... 13908 total Having said that, I like that you took inspiration from sam (unfortunately it seems like either your documentation is lacking or you have left out some of the most useful features) and try to use/integrate external tools. That is already better than most editors. Keep having fun. Marc
