[Darth-Apple]

My coding style has changed so, so much over the years. 

I taught myself at a young age. That being said, I didn't realize just how much I didn't know until I started studying computer science at university. And oh my, do you learn so much. I occasionally dabble with old code of mine, and I realize that I've learned quite a bit over the years. 

That being said, if there is one thing I learned, it's how to NOT one-line code. As it turns out, having fewer lines of code does not mean that the code is faster. (In many cases, it's actually slower. Some of the complex functions that can help you one-line sections of code are very heavy-weight under the hood. Even in python, I write my own code to multiply matrices, because Numpy's functions are far too slow for the task. )

As a result, I end up writing quite a few lines of code to do even a simple task. I try to make my code as readable as possible, and don't worry so much about the line count. I'm often told that my code is overkill (or that it takes too many lines to do something simple). yes, I know how to use complicated functions and language constructs. I just choose not to. I value stability and readability, and performance, over elegant forms of creatively one-lined code. 

That being said, sometimes less code is advantageous. With larger files, it's often harder to pin-point sections of code that exist in a huge file with 2,000 lines. It also introduces more places where bugs could exist (more code is being used), so there is often a trade off. You find yourself limited by the speed that you can type.

What are your thoughts on code's line count? Do you find that you try to make your code compact, verbose, or somewhere in between?

[Lain]

As compact as possible, with verbosity coming from basic comments explaining functionality so I don't need to look too hard to find what something does.

That being said, I do mostly write native/compiled stuff, so performance benefits are usually pretty negligible. gcc and g++ automatically compile typically slow operations to faster ones, like this:

Code:

int i = 17;
int j = i / 2;
//j compiles to i >> 1, or bitshift right by one

int j = i % 2;
//compiles to i & 1 (bitwise AND with 0x1 to isolate the last bit)

The fastest or most compact even/odd calculator I've seen in C looked something like this:

Code:

#include <stdio.h>
int main(int argc, char* argv[]){
    !(argc & 1) ? return 1 : 1;
    const char* a = "odd\0even\0";
    int(argv[1]) & 1 ? printf(a) : printf(*a + 4);
    return 0;
}

Ternary operators, bitwise and pointer arithmetic. Very minified, and although I'm not actually compiling this to test it, you get the idea. The bloat comes from taking in arguments from the commandline.

I don't write huge projects or anything, so everything gets to be around a couple hundred lines, making it pretty easy to manage and generally fast to compile.
The largest code segments I've written were exploits or malware PoC's, and that's because you'd need to write shellcode as well, then compile it, rip out the .text segment from the binary, then make a byte array out of it to use with WriteProcessMemory or whatever from WinAPI/MemoryAPI.