I see wikipedia entries for: https://en.wikipedia.org/wiki/Source_lines_of_code aka SLOC.

Shouldn't there be some other kind of metric like SCC? (source character count).. or maybe there is and I just haven't found it?

  • 2
    Nobody uses either metric. Writing more code to achieve the same result isn't necessarily bad, and by trying to make such a correlation you're optimizing for the wrong things. – Telastyn Feb 3 '17 at 20:28
  • 1
    Possible duplicate of How to determine if a programming language is verbose or terse? – gnat Feb 3 '17 at 20:29
  • 5
    While it is my opinion, this is a site asking for expert opinion widely held by the profession. Lines of code has been misused by managers for decades now. Stop it. – Telastyn Feb 3 '17 at 20:36
  • 1
    If you're looking for the efficiency of the language, we have a duplicate question for that. And while we're here, the information encoding per bit of source code is a crappy metric for programming language efficiency. – Telastyn Feb 3 '17 at 20:39
  • 2
    @foreyez: If you want to discuss the "conciseness" of code, you should probably measure number of tokens rather than number of characters. Otherwise you would just encourage using one-letter variable names. – JacquesB Feb 3 '17 at 20:59

There is such a metric - character count - and Stack Exchange has an entire site dedicated to it: Programming Puzzles & Code Golf.

Golfing can be a lot of fun, but it's not overly useful for commercial programming. Your typing speed is rarely the limiting factor on how quickly you produce working code, so having to type twice as many keystrokes to accomplish a task isn't a problem.

Remember, source code is read more often than written. Saving keystrokes is a false economy because it often makes the code more difficult to read.

| improve this answer | |
  • well SLOC exists - your argument against SCCC could apply to SLOC as well. But people found it relevant enough to call it SLOC. (Just like I'm gonna start calling this SCCC if nobody can give me a general term and/or better acronym to use) – user19718 Feb 3 '17 at 20:53
  • I agree. SLOC was an attempt to treat programmers as assembly line workers & measure their output accordingly. It didn't work. – Dan Pichelman Feb 3 '17 at 21:02
  • Forget managers. I'm a coder deciding what technologies to use. For example, ever since react.js came out I've been comparing jquery code to it and found that I need to type twice as much in react. Therefore I chose not to use react. It's a pretty simple metric actually. – user19718 Feb 3 '17 at 21:09
  • 2
    As long as you're the only one who ever has to read your code, go for it. – Dan Pichelman Feb 3 '17 at 21:10
  • 2
    @foreyez tt sms lk grt id uv rly slvd imptnt pblm – jonrsharpe Feb 3 '17 at 22:00

Character count of source code is not commonly used as a metric because it it not really useful. The reason is most of the characters in a mainstream language will be identifiers, so the choice of shorter or longer identifiers will dwarf other factors in measuring the conciseness of the code.

For example the C# method declaration A B() is shorter than the JavaScript function b(). But with a different choice of identifiers if would be opposite.

Generally you want conciseness of code (reduce boilerplate and accidental complexity) but at the same time you want meaningful and descriptive identifier names. Since these two factors may have opposite effect on the character count, it is not really useful as a metric for neither quality and complexity.

Lines of code (LOC) is a problematic metric, but at least it is not affected by size of identifiers. Counting the number of tokens (rather than characters) would probably be more useful for your purpose.

The only context where measuring character count makes sense is if you are only concerned about physical size of the source code (e.g. for the purpose of deciding how much storage you need on the build server or something like that) in which case you would just use bytes, e.g. source code in KB or MB.

| improve this answer | |
  • Not sure if I buy this. Identifiers, variables names, etc for a given programmer are generally the same. So if I call a variable 'myBox' in one language I'll probably do the same in another language. Besides "A B()" would never happen. It'd probably look more like "public void Speak()" which would still be more characters than "function speak()". – user19718 Feb 4 '17 at 14:44
  • Also strongly typed languages are a factor and so is OOP, which is generally more verbose. 'private void SomeMethod(string msg)' is going to be more code than 'function someMethod(msg)' because you need to deal with types. And not just in the function name, but pretty much everywhere inside that function. casting types, declaring types, etc becomes verbose. So obviously the amount of characters would be less in say javascript than c#. This is a no brainer. – user19718 Feb 4 '17 at 14:52
  • also file sizes are different between operating systems. for example unix ends lines different than lines ending in windows. but a character count would ignore whitespace so it wouldn't be affected. – user19718 Feb 4 '17 at 15:05
  • @foreyez: Yes some languages are more verbose than others. I'm just pointing out character count is a really bad metric for quantifying this. – JacquesB Feb 4 '17 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy